The Risks Digest

The RISKS Digest

Forum on Risks to the Public in Computers and Related Systems

ACM Committee on Computers and Public Policy, Peter G. Neumann, moderator

Volume 17 Issue 85

Weds 6 March 1996

Contents

o Compromise Bills on Data Encryption
Edupage
o Re: Spamming spoof floods autoresponder@WhiteHouse
Joel M Snyder
via Prentiss Riddle
o More on Java applet loading
Li Gong
o Re: Telephone exchange "collapses" following bombing
Lauren Weinstein
Dave Hinerman
o Power, sensors, and alarms
Jim Hudson
o My all-time favourite leap-year bug
Max Hadley
o Leap years at Digital [FORWARD]
Lord Wodehouse
o Leaping to conclusions
Sidney Markowitz
o More on leap-year calculations
Gareth Husk
o More on Excel and Lotus Dates (leap year 2000)
Frank Dougherty
o Re: 29 Feb 1900 and Excel
Steve Loughran
o Automated PC services
Matt Welsh
o The risks of assuming you know a domain ownership...
Jot Powers
o Re: PKZip Virus Alert
Dan Zerkle
o Info on RISKS (comp.risks)

Compromise Bills on Data Encryption (Edupage, 5 March 1996)

Educom <educom@elanor.oit.unc.edu>
Tue, 5 Mar 1996 21:09:57 -0500 (EST)

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)


Re: Spamming spoof floods autoresponder@WhiteHouse

Prentiss Riddle <riddle@is.rice.edu>
Wed, 6 Mar 1996 09:02:34 -0600 (CST)

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: <a href="mailto:jms@tennis.opus1.com">jms@tennis.opus1.com</a> (Joel M Snyder)<br /> > 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.


More on Java applet loading (Re: RISKS-17.83)

Li Gong <gong@csl.sri.com>
Tue, 5 Mar 1996 18:08:08 -0800 (PST)

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 <A HREF="file:/tmp/play.html"> Fancy page </A>. 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/

Re: Telephone exchange "collapses" following bombing

Lauren Weinstein <lauren@vortex.com>
Tue, 5 Mar 96 16:53 PST

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

Re: Telephone Exchange Collapses After Bombing

Dave Hinerman <hinermad@sanfrancisco.aldiscon.com>
Wed, 6 Mar 96 09:06:22 PST

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

Power, sensors, and alarms

Jim Hudson <jim@lightning.met.fsu.edu>
Wed, 6 Mar 1996 11:48:29 +0500

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]

My all-time favourite leap-year bug

Max Hadley <mrh@shl.co.uk>
Wed, 06 Mar 1996 10:24:33 +0000

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

Leap years at Digital [FORWARD]

Lord Wodehouse <w0400@ggr.co.uk>
Wed, 6 Mar 1996 15:52:29 +0000 (GMT)

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.


Leaping to conclusions

Sidney Markowitz <sidney@atg.apple.com>
Tue, 5 Mar 1996 15:43:32 -0800

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 <sidney@atg.apple.com>

More on leap-year calculations (RISKS-17.83)

Gareth Husk <gareth@thaw.demon.co.uk>
Tue, 5 Mar 1996 21:47:37 +0000

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]


More on Excel and Lotus Dates (leap year 2000)

"frank dougherty" <>
Tue, 5 Mar 96 16:33:52 -0700

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

Re: 29 Feb 1900 and Excel

Steve Loughran <slo@HPLB.HPL.HP.COM>
Wed, 06 Mar 1996 16:07:55 +0000

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

Automated PC services (Elliot, RISKS-17.83)

Matt Welsh <mdw@CS.Cornell.EDU>
Tue, 5 Mar 1996 20:52:17 -0500

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 &quot;automatic&quot; 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:

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

The risks of assuming you know a domain ownership...

Jot Powers <jot@tmp.medtronic.com>
Tue, 5 Mar 1996 12:23:15 -0700 (MST)

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

Re: PKZip Virus Alert

Dan Zerkle <zerkle@cs.ucdavis.edu>
5 Mar 1996 21:59:49 GMT

T Bruce Tober <octobersdad@crecon.demon.co.uk> 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.

Please report problems with the web pages to the maintainer

Top