Please try the URL privacy information feature enabled by clicking the flashlight icon above. This will reveal two icons after each link the body of the digest. The shield takes you to a breakdown of Terms of Service for the site - however only a small number of sites are covered at the moment. The flashlight take you to an analysis of the various trackers etc. that the linked site delivers. Please let the website maintainer know if you find this useful or not. As a RISKS reader, you will probably not be surprised by what is revealed…
Stray Rodent Halts Nasdaq Computers, by Kenneth N. Gilpin
NYT Thursday, Dec 10, 1987, p.33
An adventurous squirrel touched off a power failure in Trumbull, Conn.,
that shut down the National Association of Securities Dealers'
automatic quotation service for 82 minutes yesterday.
A Nasdaq official estimated that the power failure might have kept
slightly more than 20 million shares from being traded. [......]
The breakdown was also felt at stock exchanges around the country on
which options on over-the-counter issues are traded
Power in the Trumbull area, where Nasdaq's main computer center is
situated, was restored by the United Illuminating Company shortly after
the squirrel lost its life - and Nasdaq its power - at 10:43 A.M.
But a power surge that accompanied the utility's resumption of
service disabled Nasdaq's mainframe computers and seriously damaged the
electrical system at the complex, making it impossible to use backup
generators.
Nasdaq officials then switched to a backup computer system in
Rockville, Md. By 12:05 P.M., service had been partly restored.
Full service was available by 2:30 [the Nasdaq official] said . [......]
Well, I guess a martyr to one segment of the mammal population is a scapegoat
to another. The disruption could have been more serious if more people hadn't
squirrelled away their savings after black monday.
peter ladkin
From CRTNET, number 115. From T3B%PSUVM.BITNET. Subject: Christmas Virus Warning If you are at a CMS site and receive a program called CHRISTMA EXEC, please (a) warn your postmaster and (b) discard the exec (or keep a copy for the postmaster to look at, but DO NOT RUN IT). This exec paints a Christmas tree on your screen and then sends itself to everyone named in either your NAMES or NETLOG files. The result is potentially serious stress on Bitnet and on your local spool system, and possibly a few system crashes here and there as the number of reader files soars and exceeds the maximum. The Christmas tree isn't all that pretty, and the joke is pretty mean. A word to the wise. Your postmaster will thank you. Michael Sperberg-McQueen
(From the Lafayette (Indiana) Journal & Courier, December 12, 1987. Quoted
without permission.)
IBM Woes — Computerized grinch jams the mail
BINGHAMTON, N.Y.- A computerized Grinch invaded IBM's electronic
mail Friday.
An illegal software-style so-called Christmas card sent through
IBM's electronic mail jammed desk-top computer terminals, spokesman
Joseph E. Dahm said.
The so-called virus program forced plant officials to turn off
internal links between computer terminals and mainframe systems to
purge the message, Dahm said.
IBM sources say the link was off from 45 minutes to 90 minutes
depending on the location.
The program is known as a virus because it enters computer programs
and replicates itself automatically.
Curious employees who read the message titles "Christmas" in the
morning electronic mail discovered an illustration of a Christmas tree
with "Holiday Greetings" superimposed on it. A caption advised "Don't
browse it, it's more fun to run it."
"That was the hook," an IBM source said. "A lot of people thought
they could take a peek and then kill the message, but once opened, it
was too late."
The program automatically entered a security log listing contacts
made from the individual computer terminal, duplicated and mailed
itself to new victims.
Like a Pandora's Box, once opened, the program rarely accepted
commands to stop, sources said. Operators who turned off their
terminals to stop the Christmas message lost electronic mail or
unfinished reports not filed in the computer.
This article seems to have a lot of things in it that the reporter didn't
understand. I assume that the "terminals" in question are really PC's
connected to the mainframes; for one thing. Plus, I presume the "Don't
browse it" refers to the VM/CMS "BROWSE" command used for looking through
files, and not just to the regular English word.
Does anyone have any more info from a source which understands all the
big words?
--Dave Curry, Purdue University
From recent postings it sounds like Personal Computer viruses
are getting to be a problem. In 1982 when I wrote my Virus, nobody I knew
thought such things could even exist. When I explained what I had made to
fellow hacker types, the usual reaction was "What a wonderful idea! But an
innocuous virus is boring. I want to create an EVIL one...". Given this
reaction, and the increasing knowledge of how such things work, I would
expect the number of viruses to increase.
What strategies can we use to protect ourselves? Best, of course,
is to make it impossible. Make the DOS area on the disk read only. Put DOS
in rom on the machine. Write protect as many disks in your collection as
feasible. Make sure write protection is done in hardware.
Whenever a new disk is used for the first time, compare the DOS
on that disk with the DOS in memory. If they don't match, issue a warning.
Make a program that performs such a check a standard utility.
The best solution, I think, is to simply make writing a Virus
difficult. Don't leave any convenient holes in DOS where a Virus can hide
out. Have many places in the boot process where parity checks on pieces of
DOS are done. Have unused bytes scattered here and there in DOS that are
different in every copy of DOS sold. Have code in ROM that performs
some sort of verification before booting a disk. Have several different
versions of this ROM in use, sensitive to different things, so that you
can't assume a virus that works on your machine will also work on all
machines. Use self-modifying code in the boot process. Have several different
ways that DOS can be layed out on the disk, and pick a random one at
initialization time.
While none of these schemes would make a Virus impossible, any of them
would make creating one very tedious. I think the only reason we aren't
experiencing a plague of viruses already is that it is a fair amount of
work to create one. It is also a lot more work to create a "careful" virus
than it is to create a "careless" one. Most of the viruses I have heard
of are not purposefully evil, they just don't bother to check that they
aren't accidentally damaging something.
postmaster@decwrl.dec.com
Subject: New chain letter running around internet/usenet
Yes, there's another chain letter running around out there. We've just wiped
out a few hundred local copies, and it looks like it got here after bouncing
around a DECnet site somewhere. The oldest letter in the chain is from
'DECWSE::ROST "Randi Rost"' but of course I've no idea if that's the original
point of origin. There's no telling how much mail spooler space or xmit time
is being chewed up by this @($#*&!@ letter, of course; but I figured I'll tell
y'all...well, those of you that didn't already know the good news.
Rich
[Enormous sequential history of the chain letter deleted... PGN]
In a recent job, I was involved in processing Master Card and Visa credit card charges, and it seems to me that their automated processing system is enormously vulnerable to fraud. Let me explain how it works. We were taking a lot of credit card orders over the phone, and had all of the order information in a data base. It seemed like a bad idea to print out zillions of charge slips, so I investigated submitting the charges on-line. It turned out to be unbelievably easy. Readers are doubtless familiar with the verification terminals found next to cash registers, into which a clerk puts the card, keys in the amount of the sale, it calls in and comes back with an approval code or denial message. It turns out that the terminals can do considerably more than that. They can post charges to a customer's bill, making it unnecessary to physically send in a slip, and can also post refunds. Many stores use an "auth/post" transaction which authorizes and posts a charge in a single operation while you wait. When the terminal runs the transaction, it calls a local concentrator which sends the request to the Giant Bank Computer in Omaha, which in turns sends the request to the cardholder's bank, with the bank sending back the response. The authorization code the merchant writes on the check comes from the cardholder's bank. I've watched while requests for European cards ran, and they take only a few more seconds than usual. It's pretty impressive. Funds from transactions posted by 7:00 PM each day are supposed to be available in the merchant's bank account the next morning. The Giant Bank Computer sends a printed log of posting transactions which usually arrives about a week after the actual transaction. Each call that posts anything produces a separate log page. The bank, by the way, thinks this is all great since they are spared all of the physical work of processing the charges, and charged us about half what they would have had we sent in slips. The protocol between the authorization terminal and the concentrator is unencrypted 300 baud ASCII. It took me about a day to write a program for a PC that implemented the protocol and that we used to process our thousands of credit card sales via auth/post transactions. The terminal calls in, and after the concentrator answers it sends a record consisting of the merchant's account number, the customer's account number, the amount to charge, and a code indicating what kind of transaction to perform. The response is the actual string displayed on the transaction terminal, e.g. "AUTHORIZED: 123456". The messages in each direction are protected by a simple one-byte checksum, with messages with bad checksums being ignored. There is no log-on or log-off protocol; the terminal calls up, sends and recieves as many transactions as it wants, and then hangs up. The first problem is that there is no protection against duplicated transactions when a message is thrown away due to a bad checksum. We had a few, most of which we fortunately noticed and fixed before the customer got the bill, and would probably have had many more had the concentrator not been physically very close on a clean phone line. More importantly, this scheme seems awfully easy to spoof. Merchant numbers are usually printed next to the merchant's name on a charge slip. Card numbers are all over the place. For example, imagine that I just bought something at a store that runs a slip, then does an auth/post on its terminal and then just files the slip. (I know lots of stores that do that.) I then run home and call up from my PC, sending a refund transaction for the same amount and merchant number. The merchant probably would never notice the refund in the blizzard of paper that comes from the Giant Bank Computer, or if it did, would probably assume that it was a voided sale or accidental overcharge. Another less subtle risk is that were someone to sabotage the Giant Bank Computer, as far as I can tell all bank card charges would stop. I'm sure they have good physical security and backups, but even a day or two of downtime could cause major trouble for a lot of merchants. We probably have yet another case here of banks using security through obscurity (which is why I'm certainly not going to go into any more detail about the protocols.) I've heard that they are very touchy about people discussing the checksum algorithm used in credit card numbers, even though the algorithm is printed in the ANSI standard for financial transaction cards. The online transaction scheme is, to put it mildly, a much greater exposure. American Express was much less willing to automate the procedure — they were happy to do on-line authorizations through the same simulated transaction terminal. We still had to send in physical charge slips. I thought they were just being obnoxious, but upon reflection, I can see that they may have had their reasons. John Levine, johnl@ima.isc.com or ima!johnl or Levine@YALE.something
A colleague's BMW 525e developed a disturbing fault. After we had returned to it on several occasions to find all the doors unlocked, we set a trap. After parking it, we locked the doors, went 20 yards away and waited. Five minutes later, we heard the central 'locking' system unlock all the doors. The fault was traced to a loose wire. Martyn Thomas, Praxis plc, 20 Manvers Street, Bath BA1 1PX UK. Tel: +44-225-444700. Email: ...!uunet!mcvax!ukc!praxis!mct
An EEC Directive, mandatory throughout the Community from Summer 1988, imposes strict (ie no-fault) liability on manufacturers of products which cause personal injury or damage to personal property as a result of a manufacturing defect. For imported goods, the original importer into the EEC is liable. Liability is strict: the purpose of the Directive is to ensure that injured people can recover damages without having to prove negligence (usually impossible and always expensive). The UK has enacted the Directive as Part 1 of the Comsumer Protection Act 1987 (which comes into force on March 1st 1988). The UK has included a defence: "that the state of scientific and technical knowledge at the relevant time was not such that a producer of products of the same description as the product in question might be expected to have discovered the defect if it had existed in his products while they were under his control". This defence is not allowed in France, the Netherlands, or Luxembourg. West Germany allows the defence except for Pharmaceutical products. It is expected that the Act will greatly increase the adoption of software Quality Assurance (to conform to ISO standard ISO 9001) and the use of mathematically rigorous specification and development methods (VDM, Z etc). Martyn Thomas, Praxis plc, 20 Manvers Street, Bath BA1 1PX UK. Tel: +44-225-444700. Email: ...!uunet!mcvax!ukc!praxis!mct
Text in << <> was lifted without permission from the
"Sydney Morning Herald" Friday Dec. 11 1987
<< The Advance Bank sent a Christmas letter to a Manly
account holder. It read: "Dear Valued Customer, On
behalf of your local branch team, may I wish you a
very safe and happy Christmas 1987, and a prosperous
1988." The man died earlier this year - and the
bank recognised this by addressing the letter to
Mr Arthur .... Decd. <>
An example (presumably) of blindly asking a computer to print out one
christmas letter for each human customer (as against company or corporate
entity) without first checking to see if the person is still thought to be
alive (by the absence of contary notice, such as a death certificate sent to
the bank to allow access to the deceased's account). The Bank did receive
notice, otherwise they would not have marked it to be sent to a person "Decd."
Mail: Bill Lee, Dept. Electrical & Electronic Engineering, University College,
UNSW, ADFA, Canberra. 2600. Phone: (062) 68 8193, Telex: ADFADM AA62030,
ACSNET: "bill@eeadfa.ee.adfa.oz"
In RISKS 5.67 (01 Dec 87), Rodney Hoffman indicated that news accounts concerning the recent failure of the 9020 computer at the Los Angeles Center made no mention of a date for installation of a replacement computer system. For your information, the replacement system has been installed at Los Angeles and is scheduled to be fully operational by March 01, 1988. The replacement program has been proceeding ahead of schedule, with replacement computers operational at about one-third of the centers. All sites are scheduled to be operational by June of 1988. The 9020 computers are being replaced with dual redundant IBM 3083 processors which will rehost the existing applications software. Reports from the field indicate that the reliability of the new systems is significantly better than that of the 9020 as a result of the new hardware and improvements in the operating system. However, the new computers are running 18-year-old software, and the display channel computer will not be replaced until the Advanced Automation System is introduced in the next decade, so it may still be necessary occasionally to shift to the less capable backup system, hopefully much less frequently.
There was a famous incident at an AT&T CO in Manhattan many years ago when a
fire destroyed much of the office. The rebuilding program was so intricate and
extensive that it was written up in a technical journal. Recently a similar
thing happened in Brooklyn, but I don't have the details. I was told at a NAS
meeting yesterday that AT&T has a videotape documenting the rebuilding effort.
Apparently, most of the effort goes into re-coppering and re-framing the
loops. I would guess that extensive use of highly multiplexed glass might make
such rebuilding much easier. Maybe the increase in robustness in the face of
massive destruction of CO facilities will balance the vulerability to backhoe
attack.
Dave
Please report problems with the web pages to the maintainer