Subject: RISKS DIGEST 17.85 RISKS-LIST: Risks-Forum Digest Weds 6 March 1996 Volume 17 : Issue 85 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, etc. ***** Contents: [*The leap-flurry may die down soon, but the problem lingers on.*] Compromise Bills on Data Encryption (Edupage) Re: Spamming spoof floods autoresponder@WhiteHouse (Joel M Snyder, via Prentiss Riddle) More on Java applet loading (Li Gong) Re: Telephone exchange "collapses" following bombing (Lauren Weinstein, Dave Hinerman) Power, sensors, and alarms (Jim Hudson) My all-time favourite leap-year bug (Max Hadley) Leap years at Digital [FORWARD] (Lord Wodehouse) Leaping to conclusions (Sidney Markowitz) More on leap-year calculations (Gareth Husk) More on Excel and Lotus Dates (leap year 2000) (Frank Dougherty) Re: 29 Feb 1900 and Excel (Steve Loughran) Automated PC services (Matt Welsh) The risks of assuming you know a domain ownership... (Jot Powers) Re: PKZip Virus Alert (Dan Zerkle) ABRIDGED info on RISKS (comp.risks) ---------------------------------------------------------------------- Date: Tue, 5 Mar 1996 21:09:57 -0500 (EST) From: Educom Subject: Compromise Bills on Data Encryption (Edupage, 5 March 1996) Legislation has been introduced in both the House and Senate to permit the export of data encryption hardware and software if similar technology is available from foreign suppliers. The bills affirm the right of U.S. citizens to use any type of encryption equipment domestically, and prohibit the mandatory use of special keys that would allow law enforcement officials access to encrypted messages. In addition, the legislation would make it a crime to use encryption technology in the commission of a crime. (*The New York Times*, 4 Mar 1996, C6) ------------------------------ Date: Wed, 6 Mar 1996 09:02:34 -0600 (CST) From: Prentiss Riddle Subject: Re: Spamming spoof floods autoresponder@WhiteHouse I thought you might be interested in some of the measures allegedly taken by the White House sysadmins to prevent a total meltdown of its mail service. -- Prentiss Riddle riddle@rice.edu -- RiceInfo Administrator, Rice University / http://is.rice.edu/~riddle * -------------------------- Forwarded message -------------------------- > Date: 9 Feb 96 16:03:20 -0700 > From: jms@tennis.opus1.com (Joel M Snyder) > Subject: High mail volumes at whitehouse.gov > Organization: Opus One, Tucson, Arizona > Newsgroups: comp.mail.misc,comp.security.misc,news.admin.net-abuse.misc > > Good day. By way of introduction, I'm the consultant who did the > "anti-mailstorm/anti-mailbomb" software that runs on the MX host for > WHITEHOUSE.GOV. Now that the Telecom. Act of 1996 has been signed, > the volume of mail through WHITEHOUSE.GOV has gone up significantly. > For example, there were about 85,000 lines in the mail log file yesterday. > > Most of that is just people who want to express their opinion. However, > several misguided individuals have decided that they want to throw a monkey > wrench into the works by storming the President's e-mail. > > I'm writing this to let any system administrators out there know that you > may find mail from your site to WHITEHOUSE.GOV is not moving very quickly. > This is normal; it's a sign that the automatic protections of that system > have kicked in. > > Without going into details, if too many messages come from a single site, > the mail handler will throttle back accepting messages. Eventually, > though, the mail will be accepted for delivery. If you have legitimate > mail, it will eventually get through (many messages from the same > correspondent will be flushed without acknowledgement). However, > correspondents who were used to getting a reply within seconds telling them > that their message was accepted may see a substantial delay. > > Finally, if any users on your site have any delusions about the effect of a > mail bomb or storm of mail, let me help you dispel them: (1) no one > important enough to make a difference will be affected or know or care; (2) > if the messages are nasty or threatening enough, someone equally nasty may > come and visit; (3) what you'll succeed most in doing is ruining the > weekends and/or days of underpaid civil servants as well as wasting federal > tax dollars. > > Please feel free to redistribute this or use parts of it in your motd. > > Joel Snyder > (jms@opus1.com) > > PS: I don't read these newsgroups and am spending most of the weekend > trying to make sure that the mail system doesn't melt down anyway, so if > there is discussion on this, I won't see it. ------------------------------ Date: Tue, 5 Mar 1996 18:08:08 -0800 (PST) From: Li Gong Subject: More on Java applet loading (Re: RISKS-17.83) David Hopwood in RISKS_17.83 mentioned, "If an attacker can arrange for two files (a "Loader" class, and a dynamic library) to be installed in any readable directory on the client machine, he/she can bypass all of Java's security restrictions." This does not appear to be a bug (e.g., a slip in the implementation) but rather a design decision. It is clearly documented in Java that any applet downloaded from the local machine is not subjected to the security restrictions that apply to applets downloaded from elsewhere. This at first appears quite reasonable -- otherwise, you cannot do a lot of interesting things even locally. A security problem occurs, however, if the remote web page refers (directly or indirectly) to code that happens to exist on the client machine. For instance, the following line can be found at the bottom of my home page Fancy page . If you click on that, and if your trojan-co-worker has placed a file called play.html and its associated class files in /tmp on your machine, those applets will run. Alternatively, if someone knows that you have certain code X (applet or not) in your directory -- suppose you have been developing it as a possible attack on others -- that person may trick you into invoking X on yourself. An immediate question is which file should "file:/tmp/play.html" refer to? The one on the remote machine or the local one? There are pros and cons either way. The real problem is rooted in the fundamentally flawed philosophy that an applet you downloaded runs on the local machine as you. This goes against years of research in computer security. Such an applet, unless its authenticity can be verified to the satisfaction of the downloading client, should instead run within a confined (protected) sub-domain, and any further invocations from this code should also run within this sub-domain. (PGN can tell us all about the required and desirable properties of such a domain.) Most machines and OSs obviously do not support such confined domains. The point is whether Sun should have done the Java interpreter differently to make life safer. For instance, on Unix machines, it is possible to set uid on downloaded stuff. This is just one of the many ways to improve security within the Java execution model. Nevertheless, Java security will probably remain a news item until the day when the fundamentally flawed philosophy is changed. Securely yours, Li Gong, SRI International, http://www.csl.sri.com/~gong/ ------------------------------ Date: Tue, 5 Mar 96 16:53 PST From: lauren@vortex.com (Lauren Weinstein) Subject: Re: Telephone exchange "collapses" following bombing Assuming no significant damage to a telephone central office or supporting infrastructure, the most common cause of "collapse" (defined in this case as a dramatic form of overloading) is indeed the simple act of too many people trying to use the phone at the same time. Telephone switches (and related trunking) are designed to a designated expected maximum number of simultaneous calls, which is far less than the total number of lines/subscribers. In widespread emergency situations, that threshold can be easily exceeded. In the case of earthquakes here in L.A., the quake itself can cause its own telephone problem even before people have had a chance to reach for the handset--the quake can knock so many phones off the hook that (at least initially--there are timeouts in modern switches) the switch thinks that everyone and his brother is trying to make calls. Phones off hook also can fool some people into thinking that their line is dead, since most modern switches, after a few minutes of tones and recordings, will only put forth silence until all phones on a line have been hung up and reset. If an extension phone is off-hook under a pile of books, it's easy to miss (especially in the dark!) However, the most common cause of frustration during overload events is that people are not patient enough. Modern switches establish a queue for providing dialtone. Under normal conditions, you typically get a dialtone essentially immediately. But under overload, you might have to wait ten seconds, thirty seconds, or even for minutes. It seems like a *long* time. Most folks don't realize this and keep hanging up and picking up the phone again, trying to get a dialtone. Each time they hang up they lose their place and reset back to the end of the queue. So, in emergency situations (assuming you have a serious need that really requires use of the phone), pick it up and *wait* for dialtone. To test to see if you're still connected with the central office, simply blow into the handset microphone and see if you can hear the blowing lightly in the earpiece (this is easiest to test by blowing while alternately being hung up and off-hook). If you hear a difference, you've still got current on the line, and your connection to the switch is intact. If you wait, you'll probably get dialtone--sooner or later. (Whether or not there will be sufficient trunking for your call to get *out* of the office to your destination is another matter...) --Lauren-- Moderator, Internet PRIVACY Forum http://www.vortex.com ------------------------------ Date: Wed, 6 Mar 96 09:06:22 PST From: Dave Hinerman Subject: Re: Telephone Exchange Collapses After Bombing In RISKS-17.84, Jake Livni described an Israeli news report in which it was stated that the local telephone system "collapsed" shortly after a terrorist attack. The term "collapse" was not defined in the article. Jake also noted that people near to a disaster tend to use a nearby phone to inform others (family members, etc.) of the event, and that people who know someone near a reported disaster will attempt to call and verify that person's well-being. While a telephone system can "collapse" in a number of ways, most systems in use today go to great lengths to avoid a total failure under abnormal loading (which is caused by the human tendencies noted above). A system's performance will degrade under such conditions, but not necessarily fail completely. (This is, of course, neglecting bugs and other unpredictable situations.) While some systems may indeed fail to the point of requiring repair service, most will simply slow down until the overload dissipates. The Risk in this case is that under disaster conditions, calls to emergency services may be blocked by bystanders using up the available phone bandwidth to call Aunt Martha to say, "I'm OK, but you should see the mess!" Communications into and out of San Francisco area after the World Series earthquake a few years ago were rendered almost useless by this condition. I spoke with the commander of the Central Ohio HAZMAT (Hazardous Material) Response Team (operated by the local fire departments) two years ago. Part of his equipment is a cellular telephone, but he admitted that it is rarely used because by the time his team arrives at a disaster the locals have swamped the system and he can't get a dial tone. The Team is considering using volunteer Amateur Radio operators to provide contact with various telephone information services during a disaster, to bypass the need for local telephone access at the disaster site. Telephone systems are expensive to install and maintain, so operators design their systems to carry "normal" loads, with some reserve capacity. A system designed to carry the entire load during a disaster would make the price of telephone service prohibitively expensive. (Thereby reducing load? Hmmm...) David Hinerman Aldiscon, Inc. phone (614) 764-2490 ext 228 E-mail: hinermad@aldiscon.com fax (614) 764-2461 ------------------------------ Date: Wed, 6 Mar 1996 11:48:29 +0500 From: jim@lightning.met.fsu.edu (Jim Hudson) Subject: Power, sensors, and alarms Last Friday we had a power outage that lasted for about 2 hours. It was one of those dirty outages. The ones where the power goes off and on four or five time in the span of about two seconds, before it goes out for good. We made the decision to move our computer that serves as a file server and mail server to the other side of the computer room so we could plug it into the ups system. This computer carries a lot of baggage with it--a tape drive, external disk drives, and two printers. After we moved this equipment, the security alarm started going off in the mornings before I was coming in to deactivate it. One of our observant employees thought that the printer was the problem. So we ran some tests, and sure enough, the security system's motion sensor was detecting the paper as it came out of the printer and setting off the alarm, which also sounds an alarm in the campus police dept. We have now moved the printer to its original spot, under the motion sensor, and we are on good terms with the police again. Jim Hudson [Now you have a protector protector detector rejector? PGN] ------------------------------ Date: Wed, 06 Mar 1996 10:24:33 +0000 From: Max Hadley Subject: My all-time favourite leap-year bug On March 1st 1989 we received a support call from a user of our equipment based in the (Persian) Gulf. It wasn't working! The equipment comprises two boxes, both using the Microware OS/9 operating system (completely blameless throughout, I hasten to add). Box 'C' was a battery portable computer, with a real-time clock chip & continuous memory. Box 'D' was a volatile system where the OS was re-started at each power on. The system was developed in 1987 & first shipped in 1988. On 1/3/89, box 'C' attempted to boot box 'D' as usual. As part of this process, it set the date - to 29/2/89! The OS date validation routine in box 'D' rejected this, quite rightly. Box 'C' *knew* it had the right date - the RTC chip told it so, and rebooted box 'D' to teach it a lesson. And so the process continued (all day if necessary). It turns out that the RTC chip used - a 58274C - only has a 2 digit year counter (!). As a result, it needs a separate 2-bit leap year counter, which has to be correctly initialised. Since the initial boot of the box 'C' operating system was part of manufacture, initialising the clock chip was part of the manufacturing test procedure - which was written and tested in 1988! We had worked this out quickly enough to call our manufacturing partners in San Diego CA first thing in their morning & tell them to expect a lot of support calls that day! The problem was actually in the driver for the RTC chip, which bypassed the OS date validation code when setting the time & date. This was not the last problem we had with the 58274C clock chip, but that is another story...xxxxxxxxxx Stewart Hughes Ltd, School Lane, Chandlers Ford,Eastleigh, Hampshire SO53 4YG UK xx@shluk.co.uk +44 (0) 1703 270027 xx@shluk.uucp Fax:+44 (0) 1703 270007 ------------------------------ Date: Wed, 6 Mar 1996 15:52:29 +0000 (GMT) From: Lord Wodehouse Subject: Leap years at Digital [FORWARD] Dear Customer, The following is important information about Digital UNIX[R], formerly known as DEC OSF/1[R]. Thank you, Digital Customer Support Center SOURCE: Digital Equipment Corporation DATE: February 28, 1996 TITLE: Digital UNIX Systems Date/Time Problems - Leap Year PROBLEM: Recently Digital Equipment Corporation discovered a time keeping problem in Digital UNIX with respect to leap year recognition. 1) The 'date' command rejects February 29, 1996 (or any other leap year) as a valid date. 2) When the system time is changed with the 'date' to any date in March of a leap year and then rebooted, the system clock will lose one day. IMPACT: Reboots during the month of March will cause the loss of a day. On machines without this ECO/patch installed, the problem is seen only if the system is rebooted during the month of March. ------------------------------ Date: Tue, 5 Mar 1996 15:43:32 -0800 From: sidney@atg.apple.com (Sidney Markowitz) Subject: Leaping to conclusions I just found a URL for the Digital SPR 11-60903 that Dale Robinson quoted in RISKS 17.83, and I highly recommend it for both its completeness and its humor as an explanation of why the year 2000 *is* a leap year. The SPR can be found at http://www.southern.edu/people/bnbennet/text/lycomplaint.html -- sidney markowitz ------------------------------ Date: Tue, 5 Mar 1996 21:47:37 +0000 From: Gareth Husk Subject: More on leap-year calculations (RISKS-17.83) Another aspect of people's confusion with the rules for dates came to light the other day when I was tring to match the behaviour of two Julian functions. One, the Oracle numbers is well behaved and successfully handles the leap from Julian to Gregorian calendars in (a gap of 10 days in 1582). As has no doubt been discussed before just when the adjustment of calendars were adjusted was a matter of national preference and several nations did not make the move until this century. Unfortunately the set of public domain clipper routines I encountered that had been embedded in a new system I was trying to interface with didn't understand:- The Julian Gregorian change. No leap years when the year is divisible by 100. (I assume the fact that it will get 2000 right is an accident). The documentation with the routine claimed it was accurate back to 01-Jan-0100; unfortunately it fell over for dates before 01-Jan-1901. The risk here is of course embedding 'shrink-wrapped' software in your apps and trusting it to do the job on the label. In fact this software didn't even come with disclaimers I'll post the names of the routines and the author if people suddenly wonder if their Clipper apps are going to run alright. Note: For UK/US dates in the range 01-Jan-1901 to 31-Dec-2099 they work fine. [Julienne calendars is more like it -- chopped up in thin strips around funny leap years. PGN] ------------------------------ Date: Tue, 5 Mar 96 16:33:52 -0700 From: "frank dougherty" <> Subject: More on Excel and Lotus Dates (leap year 2000) A note to followup to Tom Dickens' message regarding 29 Feb 1996 errors in Excel (RISKS-17.83) I use Lotus 1-2-3 Release 5 for Windows and Excel 5.0 on the MAC. My tests revealed the following: 1. Lotus uses a "date number" system where Day 1 is January 1, 1900. The following is a quote from the Lotus Help file: date number A number from 1 through 73050 that 1-2-3 assigns in sequence to each date from January 1, 1900, through December 31, 2099. For example, the date number for July 21, 1991, is 33440. Lotus has various number formats for dates including a day-month-year format that shows today's date, for example, as 05-Mar-96. When one enters (or calculates) a date past December 31, 1999, the format changes such that February 29, 2000 is represented as 29-Feb-2000. If the column width is set to accommodate a dd-mmm-yy format, one gets a string of ********* for dates past December 31, 1999. Also, the @YEAR function returns a value of 100 for a year 2000 date (@YEAR returns 96 for a 1996 date). These results may surprise spreadsheet users who have expectations about the consistency of formatting and who do not understand the convention that Lotus uses. By the way, the maximum date for Lotus is December 31, 2099 (date number 73050). 2. The problems with 2/29 do not appear to occur in Mac version 5 of Excel. It represents 2/29/2000 as 02/29/00 is nn-mm-yy format and returns a year value of 2000 when the @YEAR function is applied. The @YEAR function returns 1996 for current year dates. Users who work with both Lotus and Excel should be aware of the differences in how the two programs handle dates. Frank Dougherty ------------------------------ Date: Wed, 06 Mar 1996 16:07:55 +0000 From: Steve Loughran Subject: Re: 29 Feb 1900 and Excel After reading about the fact that Excel 5 assumes that there is a leap year in 1900, and so all its dates (recorded as days since 1/1/1900) are wrong, I was struck by a horrible thought. Ole Automation, the Windows inter-application macro programming interface, uses data types based upon those of Microsoft's spreadsheets and Visual Basic. One of these datatypes is a date. Did this "Date" type deal with the leap year properly, or were apps using it meant to assume that 1900 was a leap year for compatibility. I bit of CD searching cam up with the following answer from from the Win32 SDK, Ole Automation, "Data Types, Structures, and Enumerations": VT_DATE A value denoting a date and time was specified. Dates are represented as double-precision numbers, where midnight, January 1, 1900 is 2.0, January 2, 1900 is 3.0, and so on. The value is passed in date. This is the same numbering system used by most spreadsheet programs, although some incorrectly believe that February 29, 1900 existed, and thus set January 1, 1900 to 1.0. So, modern apps are meant to assume that 1/1/1900 is really the second day of the year/century, rather than the first so that from 1/March/1900 onwards the value of a date calculated by a broken (assumes 29/Feb/1900 exists) application and a non broken application is the same. I can't decide if this is an elegant workaround of the problem or not... Steve Loughran, Hewlett-Packard Laboratories, Bristol ------------------------------ Date: Tue, 5 Mar 1996 20:52:17 -0500 From: Matt Welsh Subject: Automated PC services (Elliot, RISKS-17.83) In 17.83, Steve Elliot asks: >Over the weekend, Win95 erroneously took my system out of Sydney Daylight >Saving. This should not happen until the end of March. > [...] > > * What other "automatic" operations may be instigated without my knowledge? Plenty. Lots. This is, after all, what computers are for. Modern operating systems are designed to hide functionality --- especially with regards to chronic activity --- from the guise of the user. Multitasking (and multiprocessing) systems have the intentional property that "daemons" perform routine actions without the end-user's knowledge and perhaps consent. There is a very good reason for this: If the user were asked to verify and understand every subtle operation of an operating system or daemon process, no useful work could ever be done. (Could you imagine having to answer for a dialog box for every operation taking place on your system?) Unfortunately, this problem is only going to get worse --- not better. As personal computers and the operating systems that they run become more complex, much more will be going on in the system "behind your back", and you may never be aware of it. Most people are used to thinking of the PCs on their desks as predictable boxes that only do what they are explicitly told to do. MS-DOS and Mac operating systems aren't going to spawn spurious processes on you to, say, initiate their own I/O or network activity. This is, of course, something of a myth. Nearly all computers (regardless of the power of the O/S) are capable of performing "asynchronous" activity which is unknown to the user. These functions are both necessary and desirable in nearly all systems. Examples include: * Timer interrupts, and anything latched to them (say, TSRs under MS-DOS). * Time-based scheduling of processes, such as those spawned by the UNIX 'cron' and 'at' mechanisms. * Any sort of network server process, e.g., an FTP or telnet daemon which responds to stimuli from the "outside world". * Administrative programs which, say, monitor the system for viruses or perform quota services. * Viruses themselves, and all manifestations (e.g., "surprise" programs embedded in Microsoft Word documents). Computers only give the end-user the perception that he or she is in control. In reality, the operating system and all of the applications are in control. Computers and applications present an interface which implies causality. But I'm sure we've all seen enough Trojan Horses to know that this is but an illusion. M. Welsh, mdw@cs.cornell.edu Cornell University Computer Science Department ------------------------------ Date: Tue, 5 Mar 1996 12:23:15 -0700 (MST) From: jot@tmp.medtronic.com (Jot Powers) Subject: The risks of assuming you know a domain ownership... I came into work today to find e-mail waiting in my in-box from someone who had clearly reached their frustration point with their bank. It appears that this person [who will remain nameless] has had a great deal of difficulty with some banking and credit card services for the Bank of Hawaii. It just so happens that I am the owner of the BOFH.COM domain, which I use. This person sent me copies of all of his past correspondence with the bank, including his home telephone number, his VISA number and credit line. Now, being a relatively nice guy (and completely against the spirit of the domain ;) I sent him a polite note informing him of his mistake. I believe the risks are obvious, but here are a few I can think of: 1) The large number of "novices" on the internet that think they understand the naming schemes for companies. 2) The complete lack of knowledge of whois, which would have shown him that the domain certainly did not belong to the Bank of Hawaii. 3) Unsecured transmission of credit card numbers to people who have no legitimate need for them. 4) Assuming that all business can be deal with via the Internet. [P.S. My new Alpha PC with the 20 gigabyte storageworks should be here once his credit-card company approves it. ;)] Jot Powers Unix System Administrator, Medtronic Micro-Rel (602) 929-5418 jot@tmp.medtronic.com ------------------------------ Date: 5 Mar 1996 21:59:49 GMT From: zerkle@cs.ucdavis.edu (Dan Zerkle) Subject: Re: PKZip Virus Alert T Bruce Tober wrote: : In more than ten years of computing I've been hit by a virus only once. Actually, that's probably not true. .... : Phil Katz's Arc program (now known as PKZip). I : downloaded it and ran the supposedly self-extracting file. : Boom. : No hard drive. All files deleted. *Sigh*. You've just described a trojan [horse program], not a virus. It's still bad, of course. The risk? Virus detection programs typically won't help at all in detecting or avoiding trojans. Calling everything a virus might lead to an unwarranted complacency in people who have such protection software. ------------------------------ Date: 27 February 1996 (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) on your system, if possible and convenient for you. BITNET folks may use a LISTSERV (e.g., LISTSERV@UGA): SUBSCRIBE RISKS or UNSUBSCRIBE RISKS. [...] DIRECT REQUESTS to (majordomo) with one-line, SUBSCRIBE (or UNSUBSCRIBE) [with net address if different from FROM:] INFO [for unabridged version of RISKS information] CONTRIBUTIONS: to risks@csl.sri.com, with appropriate, substantive Subject: line, otherwise they may be ignored. Must be relevant, sound, in good taste, objective, cogent, coherent, concise, nonrepetitious, and without caveats on distribution. Diversity is welcome, but not personal attacks. [...] ALL CONTRIBUTIONS CONSIDERED AS PERSONAL COMMENTS; USUAL DISCLAIMERS APPLY. By submitting an item that is accepted for publication in RISKS, the author grants permission for unlimited noncommercial public distribution and redistribution in electronic and print form. Relevant contributions may appear in the RISKS section of regular issues of ACM SIGSOFT Software Engineering Notes or SIGSAC Review. RISKS can also be read on the web at URL http://catless.ncl.ac.uk/Risks RISKS ARCHIVES: "ftp ftp.sri.comlogin anonymous[YourNetAddress] cd risks or cwd risks, depending on your particular FTP. [...] [Back issues are in the subdirectory corresponding to the volume number.] Individual issues can be accessed using a URL of the form http://catless.ncl.ac.uk/Risks/VL.IS.html [i.e., VoLume, ISsue] ftp://ftp.sri.com/risks PRIVACY: For info on the PRIVACY Forum Digest and Computer PRIVACY Digest, see the unabridged INFO file at RISKS-Request (send one-line message INFO to risks-request@CSL.sri.com as noted above). ------------------------------ End of RISKS-FORUM Digest 17.85 ************************