Text File

precedence: bulk Subject: Risks Digest 20.29

RISKS-LIST: Risks-Forum Digest Friday 2 April 1999 Volume 20 : Issue 29

FORUM ON RISKS TO THE PUBLIC IN COMPUTERS AND RELATED SYSTEMS (comp.risks) ACM Committee on Computers and Public Policy, Peter G. Neumann, moderator

***** See last item for further information, disclaimers, caveats, etc. ***** This issue is archived at <URL:http://catless.ncl.ac.uk/Risks/20.29.html> and at ftp.sri.com/risks/ .

Contents: Attack of the Tuxissa Virus (Anonymous) Computer crash creates nonpersons in Zurich (Bruce Walker) tcpd warning (Kragen Sitaker) Saving files on shared computers (Bertrand Meyer) Self-opening car windows ... (Jeremy Folkes) Swedish telephone outage (Danny Kohn) Electricity over Internet (Lionel Cons) In the summertime, when your VCR screws up (Michael Bacon) Brain-dead PacBell automated payment promise system (Michael D. Crawford) Re: Unusable backup power (Terry Harris) Origins of PC / Mac Virus Vulnerability (Mich Kabay) Re: More e-mail risks (Michael H Buselli) Re: Apple Y2K (Art Delano) REVIEW: "Information Warfare and Security", Dorothy Denning (Rob Slade) Abridged info on RISKS (comp.risks)

----------------------------------------------------------------------

Date: Tue, 30 Mar 1999 05:31:34 +0200 From: Anonymous <nobody@REPLAY.COM> Subject: Attack of the Tuxissa Virus

[Contributed belatedly by several RISKS readers. TNX. Sorry we could not have included it in one of YESTERDAY'S three issues. PGN]

LART* Advisory LA-99.01.Tuxissa Original issue date: Apr. 0a, 1999 Last revised: --

Topic: Attack of the Tuxissa Virus

This advisory is intended primarily for network administrators responsible for user configuration and maintenance.

Attack of the Tuxissa Virus, March 29, 1999

What started out as a prank posting to comp.os.linux.advocacy yesterday has turned into one of the most significant viruses in computing history. The creator of the virus, who goes by the moniker "Anonymous Longhair", modified the well-known Melissa [1] virus to download and install Linux on infected machines.

"It's a work of art," one Linux advocate told Humorix after he looked through the Tuxissa virus source code. "This virus goes well beyond the feeble troublemaking of Melissa." The advocate enumerated some of the tasks the virus performs in the background while the user is blissfully playing Solitaire.

Once the virus is activated, it first works on propagating itself. It has a built-in e-mail harvesting module that downloads all the pages referenced in the user's Internet Explorer bookmarks and scans them for e-mail addresses. Using Outlook, the virus sends a copy of itself to every e-mail address it comes across.

After it has successfully reproduced, the virus begins the tricky process of upgrading the system to Linux. First, the virus modifies AUTOEXEC.BAT so that the virus will be re-activated if the system crashes or is shut down while the upgrade is in process. Second, the virus downloads a stripped-down Slackware distribution, using a lengthy list of mirror sites to prevent the virus from overloading any one server.

Then the virus configures a UMSDOS filesystem to install Linux on. Since this filesystem resides on a FAT partition, there is no need to re-partition the hard drive, one of the few actions that the Word macro language doesn't allow.

Next, the virus uncompresses the downloaded files into the new Linux filesystem. The virus then permanently deletes all copies of the Windows Registry, virtually preventing the user from booting into Windows without a re-install. After modifying the boot sector, the virus terminates its own life by rebooting the system. The computer boots into the Slackware setup program, which automatically finishes the installation of Linux. Finally, the dazed user is presented with the Linux login prompt and the text, "Welcome to Linux. You'll never want to use Windows again. Type 'root' to begin..."

The whole process take about two hours, assuming the user has a decent Internet connection. Since the virus runs invisibly in the background, the user has no chance to stop it until it's too late.

The e-mail message that the virus is attached to has the subject "Important Message About Windows Security". The text of the body says, "I want to let you know about some security problems I've uncovered in Windows 95/98/NT, Office 95/97, and Outlook. It's critically important that you protect your system against these attacks. Visit these sites for more information..." The rest of the message contains 42 links to sites about Linux and free software.

Slashdot is one of those links. "That could spell trouble," one Slashdot expert told Humorix. "Slashdot could fall victim to the new 'Macro Virus Effect' if this virus continues to propagate at its present exponential growth rate. Red Hat's portal site, another site present on the virus' links list, seems to be quite sluggish right now..."

Details on how the virus started are a bit sketchy. The "Anonymous Longhair" who created it only posted it to Usenet as an early April Fool's gag, a demonstration of how easy it would be to mount a "Linux revolution". Some other Usenet reader is responsible for actually spreading the virus into the wild. One observer speculated, "I imagine the virus was first sent to the addresses of several well-known spammers. The virus probably latched on to the spammer's e-mail lists and began propagating at a fantastic rate. With no boundary to its growth, this thing could wind up infecting every single Net-connected Wintel box in the world. Wouldn't that be a shame!"

Linus Torvalds, who just left for a two week vacation, was unavailable for comment at press time. We have a strong feeling that his vacation will be cut short very soon...

[1] http://linuxtoday.com/stories/4463.html

James S. Baughn http://i-want-a-website.com/about-linux/

[For those of you not familiar with the imagery, think about what erect short-legged flightless aquatic-bird operating-system symbol seems to be wearing a tux. But then don't ask about who the Mel in Melissa is. PGN]

------------------------------

Date: Thu, 1 Apr 1999 10:47:57 -0800 From: "Walker, Bruce" <bwalker@logicon.com> Subject: Computer crash creates nonpersons in Zurich

I found this one while surfing the web

One side effect of the year 2000 problem; crash in central computer

On Wednesday afternoon, 31 Mar 1999, the central computer of the Zurich city administration crashed due to a mistake by two officials who were working on the reprogramming the cantonal and city information systems for Y2K. After rebooting the computer, they found that important files were missing -- including those containing data on the citizens of Zurich, many of whom may have become ``officially lost'', according to a city councillor. [Source: *Zurich Tages-Anzeiger*, 1 April 1999, PGN-ed from the German and from Bruce's translation]

My comment is: where were the backup tapes?

Bruce Walker 1406 Stonewood Ct. San Pedro, Calif. 90732

------------------------------

Date: Fri, 2 Apr 1999 17:32:51 -0500 (EST) From: kragen@pobox.com (Kragen Sitaker) Subject: tcpd warning

The problem with tcpd that's being discussed on BUGTRAQ -- that a backslash at the end of a comment line has a meaning different from the one a particular user was expecting -- illustrates a larger problem.

Simple, predictable user interfaces are essential to security. If you must direct a program to take some action, and you cannot tell whether the action you have directed it to take is dangerous or not, then your system is insecure, because there is a significant chance you will accidentally do something dangerous.

You don't want DWIM in your hosts.allow and hosts.deny files. You don't want confusingly-difficult syntax, either.

In general, this is an argument against using computers to safeguard security, because computers are hard to predict. (Much harder, for example, than deadbolts.) But there are cases in which you have to do this; in these cases, it is imperative to use software that is as transparent as possible, so you can have a high degree of assurance that it will do the right thing.

qmail's config files are good in this way: very, very simple. Very hard to get surprising behavior -- at least, surprising to me. It is quite likely that new Unix users would be surprised by it frequently, and I don't know any way around that.

Usability is essential to security.

<kragen@pobox.com> Kragen Sitaker <http://www.pobox.com/~kragen/>

------------------------------

Date: Tue, 30 Mar 1999 20:06:01 -0800 From: Bertrand.Meyer@eiffel.com Subject: Saving files on shared computers

Mail from: Bertrand Meyer (Interactive Software Engineering, Santa Barbara)

Recently I used a public access computer graciously provided by HP in an American Airlines Admiral's Club. Although a long-time RISKS reader, I couldn't believe my eyes when looking under "Documents" in the Windows taskbar. Previous users had stored all kinds of Word documents, including one entitled "Confidential Settlement Terms", personal correspondence etc.

The service is extremely useful. I would be sorry if pointing out its risks incited its providers to restrict it. Still, people who offer such shared services should think of sticking on the computer a note of the form "When you are done, remember not to leave behind any personal file".

-- Bertrand Meyer, ISE, Santa Barbara Bertrand.Meyer@eiffel.com, http://eiffel.com

------------------------------

Date: Sun, 28 Mar 1999 0:20 +0000 (GMT Standard Time) From: jf@jeremyf.cix.co.uk (Jeremy Folkes) Subject: Self-opening car windows ...

A few weeks ago I took delivery of a shiny new Ford Galaxy - a 7 seater "people-mover". About two weeks later I came out of the house in the morning to find both front windows open - although I was convinced that I'd shut it all up the night before. My wife didn't really believe me, but then it happened to her - she parked it up with the windows closed, and when she returned to the car, the windows were opened. She took it to the garage, they didn't really believe her, until it happened to them....

In the good old days when windows were opened by turning a handle, they tended to stay in the position you left them. Now with electronics taking over, I had a car which would randomly open its windows when left alone. Luckily, nothing was stolen, but had I have been parked in a different place, it could have been more serious - or at the least if it had been raining I could have come back to a very wet car.

The Risks. Technology may be convenient, but it brings all sorts of new failure modes that we probably never envisaged. The cleverer it gets, the more opportunity for things to go wrong....

Jeremy

------------------------------

Date: Thu, 25 Mar 1999 14:13:31 +0100 From: "Danny Kohn" <danny.kohn@systematik.se> Subject: Swedish telephone outage

After a number of ISDN outages last year and some this year in the country, our nationally owned telco Telia had two big outages in the capital of Stockholm. It happened the first time Monday 15 Mar 1999, when millions of phone lines including the police headquarters' PBX were unusable for 8 hours! The outage was repeated exactly a week later between 10:25am and 11:05am, when incoming calls to the police PBX and to another 250 business PBXs where blocked.

The second outage is explained as an intermittent error that disturbed the communication between PBXs and the telco equipment. In addition the software that would localize the problem had a bug so that the error would not display.

The police management said that they trust Telia that this problem is now fixed.

Comming to mind is that telco exchanges are often purchased in international competition. A telco operator can not see through the software. But given the complexity neither can the producer -- we might not have bugs if they did. So, if a intruder paid by some nearby country wanted to, he could program some code "detonating" as a part of war attack.

Danny Kohn Systematik Consulting AB http://www.systematik.se +46(0)708 140300

------------------------------

Date: Tue, 30 Mar 1999 14:47:17 +0200 (METDST) From: Lionel Cons <lionel.cons@cern.ch> Subject: Electricity over Internet

There's no doubt that the Internet relies on electricity, it seems that some may have electricity relying on the Internet:

In Latest E-Commerce Play, Venture Sells Electricity Online - Internet World 3/22/99 <http://www.internetworld.com/print/current/news/19990322-latest.html>

This is a nice chicken and egg problem: which one will fail first?

Lionel Cons http://home.cern.ch/~cons CERN http://www.cern.ch

------------------------------

Date: Wed, 31 Mar 1999 12:02:48 +0100 From: Michael Bacon <streaky_Bacon@email.msn.com> Subject: In the summertime, when your VCR screws up

The UK changed to Summer Time (GMT+1 = BST) at 02:00 hours on Sunday 28 March 1999.

A national newspaper printed a warning in the TV listings, that VCR owners should not adjust the clock on their VCR until 06:00 as alteration (to BST) would invalidate the settings of the Video Plus+ system. This is a system whereby a code number is assigned to each programme (identifying channel, start day and time, and duration). This number an be entered into the VCR (via the remote control) and it automatically records the programme(s) as programmed.

My VCR takes its clock from the broadcast Teletext system and adjusts the time automatically. As warned, any programming of the Video Plus+ system would thereby be invalidated. The impact of this RISK is minor, but extend the application ...

------------------------------

Date: 23 Mar 1999 23:19:31 GMT From: "Michael D. Crawford" <crawford@goingware.com> Subject: Brain-dead PacBell automated payment promise system

I just got a recorded message telling me to call Pacific Bell at an 800 number about my overdue bill.

I've had rather amazing phone bills for the last year because my girlfriend lives in another country.

I sent them $1100 on March 20, so I figured I could call and just say the check was in the mail. Today's the 23rd.

After navigating through the maze, entering my phone number and the last four digits of my social security number, I was told that I could send the bill in two parts. I selected the option to mail it. Then when asked to enter the date I would be mailing it as 4 digits, I entered 0320. The machine asked if I meant meant March 3, 2000? No, I meant three days ago. Entering 0324 was acceptable to the machine, which is apparently unable to conceive of the concept "the check is in the mail".

Then it said I needed to mail in $164.88. I entered that I would send in $200, just because I couldn't remember how much I needed to send in. It said that was unacceptable, the minimum due was $164.88. That time I remembered it and entered in $164.88. It said that was unacceptable, the minimum due was $164.88, so I hung up.

The amount that's actually past due is $900, so that will be covered when the check is received. I figure if the money's important enough for them, they'll call me with a real human about the arrangements. -- Michael D. Crawford GoingWare - Expert Software Development and Consulting crawford@goingware.com http://www.goingware.com

------------------------------

Date: Fri, 2 Apr 1999 11:30:59 -0600 From: "Terry Harris" <tharri11@bellsouth.net> Subject: Re: Unusable backup power (Weingart, RISKS-20.24)

This is a multi-part message in MIME format.

Some years ago a friend worked at a site with an IBM 370/145. The site handled DP for several hospitals. They decided they wanted a backup power source to prevent interruptions in service. They had a battery based system installed that would give them several hours of operation. The backup system produced 208V 3 phase current at 60Hz.

It turned out that they and the backup system supplier had forgotten one thing. The 370/145 actually ran on 208V 3 phase 400Hz. The 370 included a motor-generator set to convert the current (a 60Hz motor connected to a 400Hz generator). These motor generator sets had a considerable startup current (initially about 375 Amps decreasing to about 20 over a few seconds) and the backup system could not supply that much.

If the backup system switched in fast enough that the generator did not spin down the computer was still useful. If the backup power switch wasn't fast enough it did no good as the computer could not be restarted.

The moral: understand all the requirements that the backup system will have to meet.

------------------------------

Date: Wed, 31 Mar 1999 16:58:47 -0500 From: Mich Kabay <mkabay@compuserve.com> Subject: Origins of PC / Mac Virus Vulnerability

Letter to the Editors, ATLANTIC MONTHLY.

Dear Editors:

I enjoyed Robert Buderi's historical overview of the rise of computer viruses (April _Atlantic_) -- a particularly timely contribution to public knowledge given the explosive spread of the Melissa virus and similar e-mail-enabled nuisances in late March 1999.

Unfortunately, technologically unsophisticated readers may have concluded that computer viruses are inevitable outgrowths of the nature of computers. Now, any author must select what to include or not, especially when writing within a word-count limitation. As a contribution to the discussion, not as a criticism, I did want to add a couple of fundamental points that were not mentioned in the article but that may help readers understand why we are suffering this cyberplague.

1) Computer viruses in the wild exist almost exclusively on Microsoft DOS, Microsoft Windows 3.x, 95, & 98 and Apple MacOS operating systems. For all practical purposes, there are no viruses in UNIX, MVS, VMS, MPE and other operating systems that run on workstations, minicomputers and mainframe computers. The root (no pun intended) of our PC virus woes is design decisions made long ago. Microsoft engineers decided to dispense with a security kernel -- the part of the operating system that determines exactly what kinds of operations an ordinary user is permitted to perform. The security kernel limits certain other operations to supervisory users (often known as "root") and yet others to the operating system itself. In well-behaved operating systems, changing a memory location (for example) is usually a restricted operation. Under Windows95, in contrast, every user is in effect root and programs the user runs can do anything at all. Without this vulnerability, viruses in the PC and Mac worlds would be severely limited in their effects (the "payload").

When PC and Mac operating systems introduce a security kernel into their operating systems, much of the viral payload would be defused.

2) Microsoft engineers decided to turn office software into a general programming tool. MS-Office programs include macros -- not an unusual feature for word processors and spreadsheets in the last 20 years. Unfortunately, they also decided to allow two functions that made their software vulnerable to macro viruses: (a) automatic execution at startup; and (b) access to system routines. Without these features, Word and Excel macro viruses would not be as powerful nor as virulent in their replication as they are today.

When Microsoft changes the defaults on Word and Excel to prevent automatic execution of macros, PC and Mac viruses will have greater difficulty in replicating.

Public awareness of the design decisions underlying our vulnerability may help sway software engineers towards improvements in our working environment.

M. E. Kabay, PhD, CISSP, Director of Education, ICSA Inc. -- Vermont 255 Flood Road Barre, VT 05641-4060 <http://www.icsa.net> 802-479-7937

------------------------------

Date: Fri, 02 Apr 1999 11:21:31 -0600 From: Michael H Buselli <cosine@computer.org> Subject: Re: More e-mail risks (Brown, RISKS-20.28)

> 1. If too many people use this thing, we may get spamming incidents in > which the spammer adds a PostPet attachment to the spam, ...

I think risk readers should know that Microsoft Outlook does this kind of thing now. If you want to get a guaranteed reply when someone using Outlook as their mail client looks at your e-mail, add the following header:

Return-Receipt-To: Michael H Buselli <cosine@computer.org>

Now, I've noticed that Outlook ignores the address given by this header and uses the address specified by the "Sender:" header instead, but that's not difficult to set to be whatever you want.

I used Outlook 98 to perform my tests playing with this header. I suspect that all other versions do the same. I am not familiar enough with Outlook Express to know if the risk applies to that mail client as well.

Perhaps there should be an option in Outlook to confirm or turn off these auto-responses?

Michael H Buselli cosine@computer.org || http://www.enteract.com/~cosine/

------------------------------

Date: Fri, 2 Apr 1999 09:33:33 -0500 From: Art Delano <ajd@home.msen.com> Subject: Re: Apple Y2K (Stringer-Calvert, RISKS-20.28)

> "We may not get everything right, > but at least we knew the century was going to end." > -- Apple Computer, HAL 9000 ad for Macintosh Y2K compliance

To the best of my knowledge, that wasn't used in the Apple's Superbowl commercial (the commercial is available online for download, but i feel lazy). On the other hand, the same quote had been circulating, attributed to Douglas Adams, for at least half a year.

A quick check with a search engine didn't turn up the original context of the quote, but did find Apple's citing Adams on their own website: http://www.apple.com/about/year2000/ -- as an introduction to their own Y2K compliance statement.

Incidentally, Apple's statement that currently-supported hardware and software are Y2K compatible allows them to make preemptive decisions to discontinue support for any products they may decide are better dropped than revised. While they're hardly the only company to do this, they might at least provide documentation of what has been discontinued and recommend upgrade paths, to keep their customers from guessing at what they need.

As has already been observed, even if a supported system, as shipped, will be Y2K-compatible, third-party software may not be. Users may not be willing to spend money and time and effort replacing working software with other working software that provides no apparent outward improvements. I have doubts that the average computer-using consumer has a clear understanding of the distinctions between disparate applications, utilities, and system functions, particularly in our current era of 'seamlessly' integrated software, and will blame all problems at whichever company seems to have their name most prominently displayed on the package. The confusion is probably better left as a subject for another thread.

ajd@boutell.com

[Also noted by DeRobertis <derobert@erols.com>. PGN]

------------------------------

Date: Tue, 23 Mar 1999 08:44:02 -0800 From: Rob Slade <rslade@sprint.ca> Subject: REVIEW: "Information Warfare and Security", Dorothy Denning

BKINWRSC.RVW 990212

"Information Warfare and Security", Dorothy Denning, 1999, 0-201-43303-6, U$34.95/C$52.50 %A Dorothy Denning denning@cs.georgetown.edu %C P.O. Box 520, 26 Prince Andrew Place, Don Mills, Ontario M3C 2T8 %D 1999 %G 0-201-43303-6 %I Addison-Wesley Publishing Co. %O U$34.95/C$52.50 800-822-6339 Fax 617-944-7273 bkexpress@aw.com %P 522 p. %T "Information Warfare and Security"

Denning has chosen to take an inclusive approach to the topic of information warfare, not limiting the material to attacks on "military" targets. Given the state of physical warfare, this seems to be quite realistic. It does mean that the book tends to read like a high level computer security text (small wonder) with an emphasis on intrusions and the more overt aspects of computer crime.

Part one is a foundation and background for the material to come. Chapter one looks at the great many information aspects to the Gulf War and Operation Desert Storm. One of the unusual factors reviewed is that of propaganda, or "perception management." A theory of infowar is the intent of chapter two, which outlines players and positions in a variety of ways. The theory is somewhat weakened for being strongly dependent upon the idea of the value of the information being attacked or defended, and this is an area that still requires work. Another possibly problematic area is the reliance on a "win- lose" model for data warfare, when there have been numerous instances of intruders, upon sufficient provocation, being willing to deny themselves a resource by damaging it, on the basis that the defenders stand to lose far more. (On the other hand, "bragging rights" seem to have a lot of value in the computer underground.) More detail on the players involved, and the possible types of attacks that have occurred, and might occur, are presented in chapter three.

Part two looks at the specifics of offensive information warfare. Chapter four is extremely interesting, showing that "open source," or publicly available information, can and has been used for offensive and criminal undertakings in a variety of ways. Disinformation is reviewed in chapter five, including the odd phenomenon of urban legends and Internet hoaxes. The problem of damage from insiders, including, finally, a documented case of a salami attack (albeit a rather clumsy one), is covered in chapter six. Chapter seven discusses the interception of information and communications in a variety of ways, and, as a sideline, jamming and alteration. A variety of methods of computer intrusion are presented in chapter eight. False identity, both identity theft and outright false, are examined in chapter nine. The material on viruses and worms, in chapter ten, is solid, although I was sorry to see that a great many possibilities for reproductive mayhem that have been discussed over the years went unmentioned. ("Harlie," Dr. Denning. "When *HARLIE* Was One.") (Of course, when I sent the first draft, I had, myself, spelled "Harlie" incorrectly.)

Part three looks at the opposite side, that of defence. Chapter eleven gives a good background to encryption, but, seemingly, primarily as a general concept, rather than going into detail on specific uses for protection. Authentication is dealt with in chapter twelve, and uses some of the cryptologic background. With monitoring and detection bracketing chapter thirteen, the section on firewalls seems just slightly misplaced. Chapter fourteen looks at risk analysis, planning, and some resources. The final chapter discusses defence of the nation, and national policy in this regard, with particular emphasis on the current situation in the US.

The content of this book not only presents a clear picture of a number of aspects of information warfare, but does so in a very practical manner, informed by the need to use "real world" examples. In addition, the anecdotal evidence backing the material makes the book quite readable and interesting. As a text for a course in information warfare, it is complete and solidly based. As a reference for security analysts and practitioners, it is clear and thought- provoking. For those who may merely have some interest in the topic, it is engaging and informative.

copyright Robert M. Slade, 1999 BKINWRSC.RVW 990212 rslade@vcn.bc.ca rslade@sprint.ca robertslade@usa.net p1@canada.com http://victoria.tc.ca/techrev or http://sun.soci.niu.edu/~rslade

------------------------------

Date: 23 Sep 1998 (LAST-MODIFIED) From: RISKS-request@csl.sri.com Subject: Abridged info on RISKS (comp.risks)

The RISKS Forum is a MODERATED digest. Its Usenet equivalent is comp.risks. => SUBSCRIPTIONS: PLEASE read RISKS as a newsgroup (comp.risks or equivalent) if possible and convenient for you. Alternatively, via majordomo, SEND DIRECT E-MAIL REQUESTS to <risks-request@csl.sri.com> with one-line, SUBSCRIBE (or UNSUBSCRIBE) [with net address if different from FROM:] or INFO [for unabridged version of RISKS information] .MIL users should contact <risks-request@pica.army.mil> (Dennis Rears). .UK users should contact <Lindsay.Marshall@newcastle.ac.uk>. => The INFO file (submissions, default disclaimers, archive sites, copyright policy, PRIVACY digests, etc.) is also obtainable from http://www.CSL.sri.com/risksinfo.html ftp://www.CSL.sri.com/pub/risks.info The full info file will appear now and then in future issues. *** All contributors are assumed to have read the full info file for guidelines. *** => SUBMISSIONS: to risks@CSL.sri.com with meaningful SUBJECT: line. => ARCHIVES are available: ftp://ftp.sri.com/risks or ftp ftp.sri.com<CR>login anonymous<CR>[YourNetAddress]<CR>cd risks [volume-summary issues are in risks-*.00] [back volumes have their own subdirectories, e.g., "cd 19" for volume 19] or http://catless.ncl.ac.uk/Risks/VL.IS.html [i.e., VoLume, ISsue]. PostScript copy of PGN's comprehensive historical summary of one liners: illustrative.PS at ftp.sri.com/risks .

------------------------------

End of RISKS-FORUM Digest 20.29 ************************