A colleague just gave me this juicy tidbit. Seems that his brother-in-law was with the 82nd Airborne and, upon assignment to Fort Bragg, was given an office that had never been used. He plugged a phone into the jack and the phone immediately rang. No, it wasn't telemarketers; he was greeted with a modem tone instead. Hung up. Phone immediately rang again. This repeated 24 hours a day until the Army put a trace on the call. The trace led to, get this, a Coca-Cola machine. The manufacturer had built into these vending machines the capability to call the bottling company when they were getting low on supplies and order more. Unfortunately for my friend's brother-in-law, the bottling company that owned this machine in particular wasn't interested in this option, so they didn't change the default telephone number that was programmed into the machine, and which was happened to be set to, you guessed it, the office at Fort Bragg. The Army cut the telephone cable on the Coke machine. (I guess they weren't armed at the time.) This brand of vending machine also has the capability of signalling via modem that it was out of change, full up on money, or had been broken into ("Help, I've fallen over and I can't get up..."). [Not high enough on Coke? PGN] I suppose modern machines just use FDDI. Maybe PGN could add a few candy machines to the RISKS distribution? Peter J. Scott, Member of Technical Staff | email@example.com Jet Propulsion Laboratory, NASA/Caltech | SPAN: GROUCH::PJS [The RISKS archives remind us of an earlier episode with Coke machines, reported 15 Jan 1985 in the Washington Post, describing a business from which hundreds of phone calls were billed mysteriously nights and weekends even though no one was in the building. Yes, their Coke machine was trying to phone home. See ACM Software Engineering Notes, vol, 10, no 2, April 1985, p.8, four months before we started the on-line RISKS! By the way, the latest SEN RISKS index is in the January 1992 SEN issue, just out. The New Orleans SIGSOFT '91 Proceedings are in the December issue. PGN]
I also received a revision of the specification for Automatic Vehicle Identification (AVI) equipment that Phil Agre talked about in Risks 13.09, and that I've talked about here before. I'm much happier than Phil was with the new draft. It still has lots of problems, not the least of them the lack of attention to security. However, they've done just what I wanted on the subject of privacy. I testified before a CalTrans hearing in October on the spec, and a state Senate Judiciary Committee hearing on Privacy in December, and it appears that my message got through. The new draft doesn't leave room for an identifier of the vehicle or the driver in the communication packets. At the hearing in December, Senator Bill Lockyer, the chair of the committee, made it clear to the head of CalTrans and to Les Kubel, who is responsible for collecting comments, that they were going to support anonymity in their system. That's a major victory. On to the rest of the spec. First, it won't be easy to forward a copy of the spec via EMail. The current draft is presented as a marked-up copy of the previous ones, even though it has changed massively. All deletions are presented with strike-through, insertions have double-underline, and all unchanged text has a single underline. Besides making it very difficult to read, this also means that a scanner isn't going to be able to figure it out. Oh well. Phil misinterpreted some of the spec in his message, and asked some questions that I can answer. From: firstname.lastname@example.org (Phil Agre) the state envisages attaching [the box] to your car that broadcasts your car's vehicle identification number (VIN) when pinged by a roadsite transmitter. They aren't going to use VIN. The spec mentions a Reader ID number which is a 32 bit field that would identify the reader unit. This is as opposed to the first version, which said VIN, and the second that said "Character-based ID, identifying the vehicle. would it be necessary for every car on the road to have one of these transmitters. All the CalTrans folk and vendors I've talked to say that there's no need for every car to have one in order to collect tolls. Some are willing to say that they expect "other forces" (maybe DEA or INS?) to try to make this kind of equipment usable for tracing people's movements. There may have been attempts to make this be standard equipment on new cars. Lockyer appeared to say that the California AVI spec had better not support this "feature". Caltrans has generalized the proposal; the "AVI" equipment is no longer specifically aimed at toll collection but is now intended to support a much wider range of applications. I'll have to look at the old spec, to figure out why, but I always understood this to be the intent. I specifically remember that the previous version said that more packet types could be added later to serve other purposes. I cannot understand how automatic toll collection could work unless every car has a transponder. The spec doesn't talk about it because it's not part of the technology being designed. The following is my guess, based on how I'd build such a system. For corroboration, we should ask someone who uses the existing systems in Dallas, New Orleans, or elsewhere what their systems do. I would expect any such (toll-collection) system to be prepared for vehicles without a transponder. Some vehicles will be from out of state, some batteries will die. So, you just have cash lanes. This also allows you to take care of the cars with boxes that have run out of credit: As you approach the toll point, a sensor queries your box to find out how your balance stands. If your account is low, you see an overhead sign directing you to use the cash lane. This doesn't make it possible to collect tolls every half-mile, but it's fully capable of supporting toll roads like the ones we currently have, or private toll roads, which could be limited to vehicles which had the units. Phil is right, however that there are lots of other issues which are left unaddressed by the spec. The folks at CalTrans aren't interested in listening to these, so you might as well address them to your state congresscritter. There's a new draft with a new deadline of February 28, so if you want a copy or to comment on the spec itself, write to: Les Kubel, Chief Office of Electrical and Electronics Engineering Department of New Technology, Materials and Research PO Box 19128 Sacramento, California 95819-0128 Chris
I must strongly disagree with the following comment in the discussion of the damages caused by the Dutch hacker's break-ins: >If restoring back-ups costs tens of thousands of guilders, something is >terribly wrong at the VU. Every system manager that uses a legal copy of the >operating system has a distribution version within easy reach. Rebuilding the operating system for a small workstation takes at least a half-day. Re-editing all site-specific files, such as pasword files, network host tables, mail aliases, and all site-specific privileged files will certainly take several more days. For a large site with networked disks and distributed resources, the cleanup must extend to all other systems that the transgressors may have reached. This is a difficult and non-trivial task. Please do not assume that I agree with other statements in the article. Martin Minow email@example.com
Here in the UK the BBC had a quiz on a Saturday night show - during the show they asked a simple question and you phoned in the answer and a randomly selected person with the correct answer was phoned back at the end and told what prize a "celebrity" had won for then (the quotes are due to the fact the the first "celebrity" was Eddie the Eagle - the UK's famously bad ski-jumper). The next week British Telecom announced that during the show 1.25 million calls had been attempted on the line, but only 7,000 had been answered by the BBC! In the past the BBC have had phone polls e.g. on capital punishment when that was being debated in parliament, and people complained that the 50-50 result was due to the capacity of the phone system and not public opinion as both lines seem to have become overloaded. david shepherd: firstname.lastname@example.org or email@example.com tel: 0454-616616 x 625 inmos ltd, 1000 aztec west, almondsbury, bristol, bs12 4sq
Does anyone have any other information about this than the newspaper article? The account in the Independent doesn't make it sound like it was a computer error although the article appears to blame the computer. The following article about faulty computer control of radiotherapy treatment is reprinted in its entirety ... A computer programming error meant that ... But it later says that: The physicist who made the mistake by introducing an unnecessary correction factor when a new planning computer was installed in 1982 ... Medical physicists compute the dosage to be given to the patient (using physicians instructions about desired treatment). If the physicist did not know how to compute a proper dosage, it does not matter whether the computation was done by hand, on a calculator, or by a computer. It seems strange to blame this on a programming error. Did the physicist really do the programming? Was there treatment planning software already installed on the computer and the physicist just entered some factors (i.e., data)? If the programmer was told by an expert to implement a particular formula that is incorrect, how could this error ever be found by testing or any other method that involved software engineering techniques? If a person drives a car into a fence, is it reasonable to blame the car? This is not at all related to what happened with the Therac-25. nancy
With regard to computer risks in general: I think it is time to establish licensing of software engineers, and that there should be an independant review body for such critical software of the sort that we literally place our lives directly in its care. Many programmers of such systems have no knowledge whatsoever of the techniques of reliable programming. They were the scientist, or expert, or whatever on the object under software control, and were chosen to write the program because they could hack out something that worked. Consequently, they turn out spaghetti. Do you want your child to be the next Therac victim? The moniker "software engineer" is used a little loosley, for my mind. I think there is a place for real software enginners, with the education in applied science that it implies. A program (5 years in Nova Scotia) of 2 years of applied science 3 years of software science professional experience. comprehensive examinations. membership in a professional society of engineers. a provincial license. a review committee. No, I am not an engineer. Donald Tyzuk Wolfville, Nova Scotia firstname.lastname@example.org
> By coincidence, it was written by a certain Jerome Canard (and no jokes about > his brother Donald, please! :-). <It's an old canard, anyway. PGN> Of course not a coincidence. As every reader of Le Canard knows, ``Jerome Canard'' is a pseudonym. The choice of pseudonym indicates that articles with this signature are probably written by the editor-in-chief, or at least a quite senior editor. > [Anyone know exactly which region the "Hexagon" is?] Please think for half a second, or look at a map. ``The Hexagon'' means France. It's a term favored by bureaucrats and journalists. (``Today, at the four corners of the Hexagon, ...'' is a famous parody of technocratic style.) ``Le Point'' is one the four major weekly news magazines. (The others are Le Nouvel Observateur, L'Express and L'Evenement du Jeudi.) Bertrand Meyer [Also noted by Martin Minow <email@example.com>]
[...] The term came into use in the 1960's after the loss of Algeria had blurred the French sense of where their borders lay. (Not too long ago, France included much of Africa and the Middle East, along with bits of the Caribbean, Latin America and Pacific Oceana.) The term is the French equivalent of "the lower 48" in the US.
VIRUS-L Digest Tuesday, 4 Feb 1992 Volume 5 : Issue 21 Date: Tue, 04 Feb 92 08:22:01 -0500 From: "Kenneth R. van Wyk" <firstname.lastname@example.org> Subject: VIRUS WARNING - DaVinci Discovers Michelangelo (PC) [Moderator's note: I received the following press release by FAX. Any typos are no doubt mine, not DaVinci's. krvw] News Release DaVinci Systems Corporation, P.O. Box 17449, Raleigh, North Carolina 27619 Tel: (919) 881-4320 Fax: (919) 787-3550 Contact: Chris Evans, Vice President of Marketing, DaVinci Systems Corporation, (919) 881-4320 DaVinci Discovers Michelangelo Virus Warns users of possible infection RALEIGH, North Carolina, February 1, 1992 - DaVinci Systems announced today that a recent shipment of eMAIL 2.0 demonstration disks and 30-day kits may be infected with a computer virus known as Michelangelo. Approximately 900 customers and potential customers were sent the infected disks. Of these, over 600 were DaVinci resellers. DaVinci Systems immediately notified its resellers of the problem via electronic mail and will mail a new set of disks to all recipients of the infected disks by February 6th. DaVinci Systems also advises anyone who has received a DaVinci eMAIL 2.0 demo disk or 30-day kit between January 20, 1992 and January 31st, 1992 not to use the disks they received. According to Bill Nussey, President of DaVinci Systems, "While there is only a slim chance of one of our customers contracting the Michelangelo virus from these disks, we wanted to take every possible precaution." The Michelangelo virus sits passively on infected machines until March 6th (Michelangelo's Birthday) when it corrupts data on a user's hard disk. FORTUNATELY, THE VIRUS CAN ONLY BE CONTRACTED BY BOOTING UP AN INFECTED FLOPPY. Because the infected disks are not bootable, most users who have received these diskettes will not contract the virus on their machine even if they run the demo or install the software on their hard disks. The only way users could catch the virus from an infected disk is if they inadvertently boot up their computers with the infected floppy in driver A while the drive door is closed. DaVinci officials are still investigating the source of the virus. Although DaVinci's master disks are routinely checked for viruses, the virus software used apparently did not detect Michelangelo. "We are now using multiple virus-detection products and insisting that our duplicating contractors also check for viruses", said Nussey. The Michelangelo virus can be detected by Microcom's Virex version 2.l1 or later or by McAfee Associates shareware program VIRUSCAN version 7.9v84 or later. DaVinci users and resellers can download VIRUSCAN from DaVinci's BBS at (919) 881-4342. Based in Raleigh, North Carolina, DaVinci Systems Corporation is the leading independent supplier of LAN-based electronic mail applications. The company's products run under acknowledged personal computer network and operating system standards such as MS-DOS, Microsoft Windows, and Novell Netware. DaVinci Systems is at P.O. Box 17449, Raleigh NC 27619. Telephone (919) 881-4320, (800) DAVINCI. FAX: (919) 787-3550. The product names and trademarks referenced are the trademarks or registered trademarks of their respective companies.
CA-92:02 CERT Advisory February 6, 1992 Michelangelo PC Virus Warning The Computer Emergency Response Team/Coordination Center (CERT/CC) has received information concerning a personal computer virus known as Michelangelo. The virus affects IBM PCs and compatibles. A description of the virus, along with suggested countermeasures, is presented below. I. Description The Michelangelo virus is a computer virus that affects PCs running MS-DOS (and PC-DOS, DR-DOS, etc.) versions 2.xx and higher. Note, however, that although the virus can only execute on PCs running these versions of DOS, it can infect and damage PC hard disks containing other PC operating systems including UNIX, OS/2, and Novell. Thus, booting an infected DOS floppy disk on a PC that has, for example, UNIX on the hard disk would infect the hard disk and would probably prevent the UNIX disk from booting. The virus infects floppy disk boot sectors and hard disk master boot records (MBRs). When the user boots from an infected floppy disk, the virus installs itself in memory and infects the partition table of the first hard disk (if found). Once the virus is installed, it will infect any floppy disk that the user accesses. Some possible, though not conclusive, symptoms of the Michelangelo virus include a reduction in free/total memory by 2048 bytes, and some floppy disks that become unusable or display "odd" graphic characters during "DIR" commands. Additionally, integrity management products should report that the MBR has been altered. Note that the Michelangelo virus does not display any messages on the PC screen at any time. II. Impact The Michelangelo virus triggers on any March 6. On that date, the virus overwrites critical system data, including boot and file allocation table (FAT) records, on the boot disk (floppy or hard), rendering the disk unusable. Recovering user data from a disk damaged by the Michelangelo virus will be very difficult. III. Solution Many versions of anti-virus software released after approximately October 1991 will detect and/or remove the Michelangelo virus. This includes numerous commercial, shareware, and freeware software packages. Since this virus was first detected around the middle of 1991 (after March 6, 1991), it is crucial to use current versions of these products, particularly those products that search systems for known viruses. The CERT/CC has not formally reviewed, evaluated, or endorsed any of the anti-virus products. While some older anti-virus products may detect this virus, the CERT/CC strongly suggests that sites verify with their anti-virus product vendors that their product will detect and eradicate the Michelangelo virus. The CERT/CC advises that all sites test for the presence of this virus before March 6, which is the trigger date. If an infection is discovered, it is essential that the user examine all floppy disks that may have come in contact with an infected machine. As always, the CERT/CC strongly urges all sites to maintain good backup procedures. The CERT/CC wishes to thank for their assistance: Mr. Christoph Fischer of the Micro-BIT Virus Center (Germany), Dr. Klaus Brunnstein of the Virus Test Center (Germany), Mr. A. Padgett Peterson, P.E., of the Technical Computing Center at Martin-Marietta Corp., and Mr. Steve R. White of IBM's Thomas J. Watson Research Center. If you believe that your system has been compromised, contact CERT/CC or your representative in FIRST (Forum of Incident Response and Security Teams). Internet E-mail: email@example.com Telephone: 412-268-7090 (24-hour hotline) CERT/CC personnel answer 7:30 a.m.-6:00 p.m. EST(GMT-5)/EDT(GMT-4), on call for emergencies during other hours. Computer Emergency Response Team/Coordination Center (CERT/CC), Software Engineering Institute, Carnegie Mellon University, Pittsburgh, PA 15213-3890 Past advisories, information about FIRST representatives, and other information related to computer security are available for anonymous ftp from cert.sei.cmu.edu (126.96.36.199).
This virus has really surprised me. When I first say it, my thought was "yet another STONED" (and not as well written), but it seems to be spreading & spreading & spreading... If Rob Slade's estimate is right, for every report we see, there are at least three other infected computers that we don't. March 6th may just be interesting. Some time ago I did a number of experiments concerning boot sectors in general since we seemed to have good protection from DOS viruses but few people were working at the BIOS level before DOS ever starts. IMHO, since over 50% of the reported infections begin at the BIOS level, then that is where the checking should start. The first experiments (written in 1988) were a set of integrity checking programs, two of which were CHKMEM and CHKBOOT (now FREEWARE) that could be used to detect all "common" viruses - I presented a paper on this at last year's Virus & Security Conference in New York (March 12 & 13 this year call (800)835- 2246 x190 for info - plug). These operate from the DOS level. About two years ago, I began studying a BIOS level approach - at this point the Intel PC is a fully functioning computer with access to all peripherals, it is just not yet a DOS (or Unix or OS/2 or...) computer. The first result was the DISKSECURE program that was designed as a technology demonstrator & performed BIOS level integrity checking and protection of the MBR, hidden sectors, and DOS boot record. Many researchers seem to like it as an additional layer of protection. DISKSECURE's biggest limitation was that it could do nothing about a floppy boot (only hardware can prevent this) and I was and am convinced that a global solution had to be software based - not for technical reasons but for logistical and economic ones. The next effort was SafeMBR - a BIOS level Master Boot Record replacement that performed integrity checking on the system and which would halt a boot if "something" was wrong and used lessons learned in DISKSECURE to avoid conflicts with the incredible array of disk controllers, BIOSes, and DOS variants that exist. SafeMBR is FREEWARE. Late in 1991, I extended the SafeMBR concepts to a similar floppy disk replacement SafeFBR to provide a generic floppy disk boot record replacement with warning messages. Concurrently with SafeMBR, I addressed the "floppy boot" problem as far as possible with software, a TSR (512 bytes needed & can be loaded "high") was written to intercept the Ctrl-Alt-Del sequence and test for a floppy in drive A. If one is found, the reboot is denied. This taught me more about the inner workings of the BIOS and the Interrupt Controller. NoFBoot was the result and is also FREEWARE. The final parts FixMBR and FixFBR were extensions of this concept used to install SafeFBR and SafeMBR. FixMBR came from hours spent disinfecting machines infected by MBR viruses and was designed to automate the repair based on the fact that ALL leave an intact partition table SOMEWHERE. Given an intact partition table, all that is usually necessary is to replace the MBR program. Generally I use the SafeMBR code to do this. For some time, I was hesitant to release these techniques but then along came the Azusa virus... FixFBR works essentially the same way except that only four Boot Parameter Blocks are needed (does not work with 2.88 Mb floppies yet). Since it also incorporates the CHKBOOT techniques, it will also flag potentially infected disks. This last is the key to the concept. None of these programs (well maybe NoFBoot) will prevent a virus infection. What they will do is to detect viruses almost immediately. Flag the "anomaly" in a way the user cannot ignore, and provide a recovery mechanism. They do not "identify 1000 viruses" but will tell you that "something" has happened at the BIOS level without going resident. They are designed as one layer in a layered protection (I use four layers myself). Similarly, either CHKBOOT or FixFBR will detect the Michelangelo virus on floppy disks and report them as "suspect". FixFBR will then remove the problem. To me this is a vital element in fighting malicious software, knowing early on that "something" has happened and isolating the abnormality to as narrow range. I personally believe that if these techniques were used globally, those viruses responsible for over half of reported infections: Stoned, Azusa, Aircop, Brain, Joshi, & Michelangelo would quickly disappear. But today there appears to be a very real threat: Michelangelo that needs to be addressed. I have never seen so many reports of a virus in so short a time before and am particularly disturbed about the number of "shrink-wrapped" reports. Consequentially, while normally I "suggest" a nominal SHAREWARE fee ($1.00) for the two "FIX" utilities, from now until 7 March, 1992, payment requirements are suspended and they may be freely used, posted, & transmitted without limitation so long as they are not modified. Padgett firstname.lastname@example.org PS: I know that the current version of these programs is in FIXUTIL2.ZIP and may be found in directory msdos.antivirus at urvax.urich.edu (188.8.131.52 - thanks Claude). Note: this is my hobby, my employer has nothing to do with this. Programs in FIXUTIL2.ZIP Length CRC-32 Name ------ ------ ---- 1331 449b4371 CHKMEM.COM 2189 2753290a FIXFBR.EXE 368 72b99d29 SUMFBOOT.COM 1357 77936de4 CHKBOOT.EXE 2219 332bf466 FIXMBR.EXE 4885 3e04a29b FIXFBR1A.DOC 749 3f347828 CHKSMBR.EXE 368 cccf71a5 NOFBOOT.COM 2602 63f3d358 NOFBOOT.DOC 4461 a1408395 CHK.DOC 366 4c0e9c20 VALIDATE.24 26118 8138037e FIXMBR24.DOC ------ ------- 47013 12 files
Please report problems with the web pages to the maintainer