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 83

Monday 4 March 1996

Contents

Spamming spoof floods autoresponder@WhiteHouse

PGN

``Racist hacker shuts down Internet provider''

PGN

Yes, folks, 2000 *is* a leap year!

Dale Robinson

Medical equipment failure - 29 Feb 1996

David Alexander

Risks of Leap Years: NY City Taxi and Limo screwup

Mark Eckenwiler

29 Feb 1996 errors in Excel

Tom Dickens

WIN95 Daylight saving

Steve Elliott

Two telephone services recognising tone dialing

Ian Chard

Java/JavaScript security breaches

Jack Decker

Flaw Found in Kerberos Security System

Edupage via Michael J. Chinni

Another Intel chip flaw

PGN

Intel "does it again" with Orion? [name withheld]

Java security bug (applets can load native methods)

David Hopwood

PKZip Virus Alert

Mike Hammoud via T Bruce Tober

Falling computer equipment

Ross Anderson

Legal Aspects of Computer Crime mailing list

Martin Minow

RISKS of public speaking

William Richard Russell

Typos in RISKS-17.82

PGN

Info on RISKS (comp.risks)

Spamming spoof floods autoresponder@WhiteHouse

RISKS List Owner <risko@csl.sri.com>

Mon, 4 Mar 96 10:11:52 PST

Today was apparently a bad day for spamming spoofs at the White Hoise.
There are reports of huge quantities of e-mail being sent to various
addresses at WhiteHouse.gov with header fields such as

  > Subject: You are now subscribed to the RISKS list

and evidently many other lists.  I received at least 10 autoresponder
replies from whitehouse.gov with the subject field

  > Subject: Re: You are now subscribed to the RISKS list

The beleaguered mail server at WhiteHouse.gov has evidently been spewing out
automatic standard responses to each mailing, with the return address coming
back to the LISTSERV.  There is now a subscription at UBVM for the Vice
President that was not there the last time I reviewed the list (which
coincidentally happened to be yesterday!).  This is a very ugly situation,
and clearly will cause the whitehouse site much grief in trying to
unsubscribe massively.  Unfortunately, e-mail spoofing is still vastly too
easy.  All of the past cries in RISKS for a much more secure infrastructure
bear repeating.  And April Fools' day is only four weeks away, to make
things worse -- reminding us of all the more benign spoofs of past years.

I hope this flurry of annoying activities does not prompt some hasty
legislation trying to make spamming and spoofing illegal.  If the
Communications Decency Act (CDA) experience is followed, and if the
California Computer Crime law is any guide (which in essence makes it
illegal to read, write, alter, or delete information -- rather broadly
making *all* uses of computers potentially illegal), we could wind up with
an unworkable definition of spamming and spoofing that includes sending
e-mail to more than one person.  Here is another argument for cleaning up
the infrastructure.  The WorldWide Information Infrastructure would come
screeching to a halt otherwise (and that acronym would unfortunately be
WW II).  PGN

``Racist hacker shuts down Internet provider''

Peter G. Neumann <Neumann@CSL.sri.com>

Sat, 02 Mar 1996 11:21:17 -0500

BerkshireNet in Pittsfield, Massachusetts, was the victim of an attack on 27
Feb 1996 in which someone planted swastikas and racist messages while
masquerading as the provider's administrator, erased data on two computers,
and then shut down the system.  It was off the air for about 12 hours.
Older deleted files were restored, but files created in the last several
days were lost.  [Source: *Palo Alto Daily News* (a relatively new local
freebie paper that is off to a good start), 2 Mar 1996, p. 6]

Yes, folks, 2000 *is* a leap year!

<Dale.Robinson@DWNPLAZA.NCOM.nt.gov.au>

Tue, 05 Mar 1996 09:25:54 +0930

Some people thought that our esteemed editor was incorrect (myself included)
when he said:

  >However, I have spent so much time lately correcting folks who think
  >2000 is NOT a leap year...

As one of the folks, I humbly submit the following...

As I am currently writing some backup dependent routines that I expect will
be here in the year 2000, I did some research, and found the following:

     An article in IBM system User International (Issue 19, Nov. 95),
     "...like many calendars, thinks there will be a February 29th in that
     year - there will not be."

     A Digital SPR (11-60903 13/10/93):
     "...a formula suggested by the Vatican librarian Aloysius Giglio was
      adopted.  It said that every fourth year is a leap year except for
      century years that are not divisible by 400..."

So we have two reports that believe 2000 is *not* a leap year.

     Further research was done and an Information Leaflet No. 48: 'Leap
     Years' by The Royal Greenwich Observatory advises that 2000 IS a
     leap year.
     (http://www.ast.cam.ac.uk/RGO/leaflets/leapyear/leapyear.html)

  [Furthermore, several folks e-mailed me today that they concluded
  from an NPR item that 2000 is *not* a leap year.  PGN]

As most readers would agree, the Royal Greenwich Observatory would have to
be a leading authority on the subject. I'll take their information as gospel!

The Risks:
...Assuming that long-held beliefs are always correct...
...That the first reference one looks at is necessarily the right one...

Dale Robinson.

   [PGN says, check it out.  The above website points out that the length
   of the tropical year is 365.24219 days.  The algorithm I know and love
   that makes 2000 a leap year because it is divisible by 400 gives 365.2425
   days in a year, an error of about three days in 10000 years.  So, sooner
   or later we will need a further adjustment.  I hope someone decides well
   in advance, to permit the programmers to get ready.  If the hassle over
   1/1/2000 is any indication, the leap-year corrections to provide the
   -.00031 day could also take a lot of expensive preparation, so we might
   as well start teaching our young programmers soon -- just in case.

   Well, are you sick of leap-year problems?  Sorry.  Three more follow,
   plus a daylight-savings problem.  PGN]

Medical equipment failure - 29 Feb 1996

David Alexander <dave_ale@online.rednet.co.uk>

Mon, 4 Mar 1996 13:08:20 GMT

In the (UK) Times newspaper, 2 Mar 1996, an article appeared reporting a
problem with laboratory equipment at Papwoth Hospital. This is one of the
main centres for the research and conduct of heart transplants and surgery
in the UK.

It seems that analytical equipment needed to carry out specialist tasks to
do with heart surgery were unable to function on the 29th of February. The
manufacturers have admitted there is a problem within the code and stated
that '...all their equipment would have the same problem.'

Fortunately all patients were treated as scheduled - other labs at the
hospital were able to carry out the required analysis with different
manufacturers machines.

David Alexander  Camberley, England  Dave_Alexander@online.rednet.co.uk

Risks of Leap Years: NY City Taxi and Limo screwup

Mark Eckenwiler <eck@panix.com>

Mon, 4 Mar 1996 22:25:55 -0500 (EST)

According to *The New York Times*, 1 March 1996, the NYC Taxi and Limousine
commission made the mistake of choosing 1 Mar 1996 as the start date for a
new, higher fare-structure for cabs.  As if the usual rigged-meter problems
weren't enough, meters programmed by one company in Queens forgot about the
leap day and charged customers the higher rate on February 29.  [Forgot, eh?]

Mark Eckenwiler   eck@panix.com

29 Feb 1996 errors in Excel

Tom Dickens <tpd6908@cfdd15.cfd.ca.boeing.com>

Fri, 1 Mar 96 19:14:03 -0800

After reading RISKS-17.81, I checked data in a spreadsheet I was working on,
and sure enough, a leapyear bug.  Microsoft Excel 3.0, both the Mac and PC
versions, has trouble with February 29th.  Enter a date for the current year
as 2/28 in a cell and it is converted to the format 2/28/1996.  Enter 2/29
and you get 2/1/1929.  I tried setting the system clock to 1992 and 1988
with the same results.  Excel version 5.0 on the PC does work for 2/29.

Note that by typing the full date, including year, as 2/29/96, and
then choosing the desired format, you can get what you want.

The risks?  Relying on automated data formatting.  Not upgrading to the
latest versions of software (upgrading has another set of risks).  And the
risk of not reading comp.risks, otherwise I would not have caught this
error.  The year 2000 should be very interesting...

...Tom Dickens   tpd6908@yak.ca.boeing.com

WIN95 Daylight saving

Steve Elliott <selliott@world.net>

Mon, 4 Mar 1996 09:11:13 +-1000

Over the weekend, Win95 erroneously took my system out of Sydney Daylight
Saving.  This should not happen until the end of March.

A search of Win95 HELP provided absolutely no information about the
parameters used to control such a behaviour.

This raises the following questions.

 * What other "automatic" operations may be instigated without my knowledge?

 * What verification of the data for such operations has occurred?

 * Where can users of such systems get accurate documentation of the
   functionality of their operating systems?

Steve Elliott, NORESE Pty. Ltd.  4, Glassop St. Balmain, NSW 2041 Australia
 selliott@world.net  +61 (41) 12 608 12   Fax +61 (2) 555 7911

Two telephone services recognising tone dialing

Ian Chard <ian@tanagra.demon.co.uk>

Sat, 2 Mar 1996 00:33:30 GMT

I just decided to check the balance on my current account using my bank's
automated telephone banking service.  I share a phone with several others,
so to avoid arguments over the bill I decided to put the call on my British
Telecom chargecard.

Both the chargecard service and the phone banking service are operated
by DTMF (tone dialing), however when I was connected to the bank and
dialed ## code for "cancel operation", British Telecom disconnected
the call and asked me if I would like to make another one.

The risks here are:

(a) To have seen me dial the ##, BT must have been monitoring the
    line for DTMF throughout the call.  This means that they monitored
    my account number and PIN as I entered them into the banking system.

(b) Anything I dial is ambiguous in this situation, unless I know
    *every* code BT understands during a call, and which ones it will
    act upon instead of passing them through to the called party.

Ian Chard, back in Manchester   ian@tanagra.demon.co.uk
NTS: G7OMZ @ GB7VRB.#38.GBR.EU    Phone: +44 161 434 6492

Java/JavaScript security breaches

Jack Decker <jack@novagate.com>

Fri, 01 Mar 1996 20:25:14 -0500

If you are running Netscape 2.0 on your system, and are at all concerned
about security or privacy, you should run, not walk to this URL:

http://www-genome.wi.mit.edu/WWW/faqs/www-security-faq.html
The World Wide Web Security FAQ

Pay special attention to questions 69 through 71.  Number 71 in particular
discusses:

* How a JavaScript page could grab a user's e-mail address from Netscape's
preferences dialog and send it across the Internet.

* A script that can open up a small window that continuously monitors the
user's browsing activity, capture the URLs of open documents, and transmit
them to a remote server.

* A script that can obtain recursive directory listings of the user's local
disk and any network disks that happen to be mounted. This information can
be transmitted anywhere in the Internet.

* How the version of JavaScript that was included with beta versions of
Netscape 2.0 contained holes that allow the user's history and cache files
(both of which contain lists of recently-visited URLs) to be captured.

I have not seen any information on this before today, so I suspect that
other Netscape users might want to know about these risks!

Flaw Found in Kerberos Security System (Edupage, 3 March 1996)

"Michael J. Chinni, (AMSTA-AR-IMN)" <mchinni@PICA.ARMY.MIL>

Mon, 4 Mar 96 9:29:09 EST

Researchers at Purdue University have discovered a flaw in the popular
Kerberos computer-security system that affects the way Version 4 of the
software creates the secret keys for encryption.  The problem does not
affect Version 5, unless it is run in a way that emulates Version 4.  The
software is supposed to select its keys randomly from among billions of
numbers, but the problem occurs in the random-number generator, which is
selecting from a much smaller pool of perhaps a million or so, making it
much easier for an intruder to crack the key.  "Basically, we can forge any
key in a matter of seconds," says Purdue professor Eugene Spafford.  The
CERT Coordination Center at Carnegie Mellon University has issued an
advisory on the problem -- CA-96.03 -- and recommends using "patches" to fix
the flaw.  < http://www.sei.cmu.edu/technology/cert.cc.html > (Chronicle of
Higher Education, 1 Mar 1996, A29)

Michael J. Chinni        US Army ARDEC, Picatinny Arsenal, New Jersey
MIL: mchinni@pica.army.mil     UUCP: ...!uunet!pica.army.mil!mchinni

  [This is old news to some of us, but has not yet appeared in RISKS.  PGN]

Another Intel chip flaw

Peter G. Neumann <Neumann@CSL.sri.com>

Fri, 1 Mar 1996 16:03:51 -0800 (PST)

After all the difficulties Intel Corp. had in response to the discovery of a
flaw in its Pentium chip [RISKS-16.57,58,59,61,62,63,64,66,67,81], the
discovery of a flaw in the new Orion 82450 chipset has caused Intel to
promise being much more open about disclosing this and other flaws.  The
Orion flaw was discussed by Intel on 29 Feb 1969.  This chipset is an
auxiliary for the Pentium pro; the flaw seriously affects I/O bus
throughput: ``as low as five megabytes per second, instead of the regular 25
to 55 megabytes''.  Intel was aware of the fault and told its primary
customers, leaving it to them whether to tell the end users.

``Intel spokesman Howard High estimated 1 percent to 2 percent of all users
would experience the poor performance though.  High noted there was a big
difference between the Orion fault and the earlier Pentium fault, saying the
former was a performance issue that would not necessarily affect everyone's
performance, while the latter related to data corruption that theoretically
would affect every user.''  [Source: Intel Discloses Flaw in Orion Chipset,
Reuter, 1 Mar 1996]

Intel "does it again" with Orion?

<[Name withheld by request]>

Fri, 1 Mar 1996 xxx

   Well, well.  Here we go again, eh?  The Orion chipset has been widely
touted in the trade press as the logical follow-up to Intel's extremely
popular "Triton" PCI chipset, this time oriented toward the P6 (oops,
"Pentium Pro").  It even included such old-time niceties as support for
parity memory, which was left out of the Triton as an economy measure.
(Hey, people can use the cheaper 8-bit memory!  Who needs the extra bit?)

   Now we find that not only is Orion flawed, but Intel is even trying to
put a new spin on their famous Pentium floating-point bug!  Today's press
releases on Orion seem to indicate that the problem most likely rests with
PCI bus handling, possibly resulting in throughput decreases up to 90%
compared with what might be otherwise expected.  Intel feels this won't
affect most users.  We don't know exactly what that means at this point.
Are they saying that the bug is so subtle that it comes up only rarely?  The
release seems to imply that all of the Orion chipsets shipped to date are
capable of exhibiting the problem.

   Or are they suggesting that only those users whose applications depend on
the full performance of the PCI bus will be affected?  You know the type,
those folks who went out and bought Pentium Pro PCI motherboards for
high-speed graphics, digital audio and video, that sort of thing.  The folks
depending on the bus to work correctly so that their dandy PCI cards will
perform up to spec.  So, maybe Intel is actually saying that so long as your
main applications are spreadsheets and word processing, or similar work that
doesn't depend on PCI bus performance, you won't notice any problem, because
you'll never stress the bus enough anyway.

   In either case, for Intel to know about this from day one, and to keep it
effectively a secret between themselves and the motherboard manufacturers,
is shameful.  What's humorous about all this is the way Intel is now
implying that the Orion bug isn't really a big problem, because they feel
that only a few of the users will notice.  But they then compare this with
the floating-point bug, which they say had a (very small) chance of
affecting anyone with the appropriate steppings of the chip.  Is there some
sort of doublespeak going on here?  Isn't a major reduction in bandwidth,
that can affect any user of the Orion chipset who needs significant
bandwidth, at least as important as the floating-point bug, if not much more
so?  First, Intel comes out with a new processor chip (the P6) that turns
out to execute the software that most people run more slowly than some of
the chips that proceeded it.  Now, the Orion problem.

   Intel's press releases today indicate that they're going to clean up
their act when it comes to early disclosure of hardware problems.  Let's
hope it's true.

Java security bug (applets can load native methods)

David Hopwood <david.hopwood@lady-margaret-hall.oxford.ac.uk>

Sat, 2 Mar 1996 23:51:49 +0000 (GMT)

There is a serious security bug in the class loading code for the Java
development kit and Netscape (all Java-enabled versions). 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. For example, the applet can read,
write and execute files on the client, with the same permissions as the
user of the browser.

The only way to avoid this bug at the moment is to disable Java. In Netscape
this can be done by selecting 'Disable Java' in the 'Security preferences...'
section of the 'Options' menu.

This bug affects all Java implementations based on Sun's source code. It is
not related to JavaScript.

Further details will be posted when Sun and Netscape have released patches.

David Hopwood  david.hopwood@lmh.ox.ac.uk

Java security bug (applets can load native methods)

David Hopwood <david.hopwood@lady-margaret-hall.oxford.ac.uk>

Mon, 4 Mar 1996 18:08:58 +0000 (GMT)

Unfortunately my news server has been off-line for the past few days.
However, I'll try to address some of the questions that were raised on
strong-java@entmp.org and in private mail about the recently-discovered bug
in Java's class loading code. The same questions have probably been asked on
RISKS and/or comp.lang.java as well.

Apparently I wasn't clear enough in stating that this bug allows classfiles
to be loaded from _any_ directory on the client machine, not simply those on
the CLASSPATH or LD_LIBRARY_PATH. This includes, for example, /tmp,
~ftp/incoming, or an attacker's home directory if he/she has an account on
the same system.

The attack requires two support files on the client's system: a classfile
and a dynamic library. Both files must be readable by the browser, and the
dynamic library must be executable (this is always true for systems that
have no file permissions). The path to the classfile from the client's root
directory must be known by the attacker in advance.

Code demonstrating the bug has been written and tested on Linux and Digital
Unix (OSF/1). It should be portable to all POSIX systems, and with a little
work, to any system that supports Java. The demonstration is very easy to
extend - hiding it within any applet would require adding only two extra
lines of code. Changing the C code to execute any command would be a
single-line change. For that reason, the code will not be described in
detail or released publically until patches are available for both Netscape
2.0 and the Java Development Kit.

David Hopwood  david.hopwood@lmh.ox.ac.uk

PKZip Virus Alert

T Bruce Tober <octobersdad@crecon.demon.co.uk>

Fri, 1 Mar 1996 23:09:46 +0000

In more than ten years of computing I've been hit by a virus only once.
Early on New Years Day 1988 I awoke, logged on to my favourite BBS (Alice's
Restaurant, Branford, Ct. USA) and happened upon what appeared to be the
then latest update to 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. Fortunately I'd done a backup a couple
of days earlier so lost only a couple of day's work. It appears that
virus is back, as detailed in the following forwarded message:

> Date: Tue, 27 Feb 1996 02:04:11 -0800
> Subject: Virus Alert** Do not download PKZ300.exe!
> From: Mike Hammoud <mhammoud@ci.tacoma.wa.us>

> To All of the NETTERS, from our computer support center at the City of
> Tacoma: There is an alert about a virus is being distributed on the I-Net,
> as a bogus PKZIP file. It has a potential to destroy all of your data on
> your hard drive.  The virus may be named PKZ300b.zip or PKZ300.exe. Do not
> download it, or execute it, and pass the word.

> FYI: The latest version of pkzip is 2.04g and the file should be PKZ204g.zip.

> Mike Hammoud  mhammoud@ci.tacoma.wa.us
> Computer Support Tacoma Public Utilities

   [This item also noted by kegill@halcyon.com (Kathy E. Gill).  PGN]

Falling computer equipment

Ross Anderson <ross@jrac.demon.co.uk>

Sat, 2 Mar 1996 11:47:24 +0100

My laser printer (an Apple Personal LaserWriter) is placed conveniently on
top of a 4 drawer filing cabinet. Recently it ran out of paper, & when I
went to refill it, I pulled the paper cassette out a little too
energetically, losing my grip on it.

As the paper cassette fell, I made a grab for it, not realising that the
large steel plate in the floor of the cassette (used for lifting paper up
ready for printing) had separated from the plastic tray. The falling steel
plate neatly sliced a small piece of flesh from a point near the knuckle of
the middle finger of my left hand, & several drops of blood fell on the
cassette before I realised what had happened & wrapped a paper tissue round
my finger to stop the flow.

The steel plate that had popped out so easily was almost impossible to put
back in place, but I eventually managed it by distorting the plastic tray
using the strength still remaining in my unmutilated hand.

Readers will be pleased to know that though the cassette's function was
unimpaired, the cassette tray suffered rather more than my finger & lost a
sizable piece of plastic from one corner. The steel plate was unscathed.

This episode highlights a number of computer-related risks :-

1. Falling computer equipment can be dangerous, both to itself & to people

2. The risks from falling computer equipment usually increase with the height
   from which it falls

3. People should not try to catch bits of computer equipment when they fall.

4. If you do try to catch falling computer equipment :-
     - beware of large bits of steel with sharp edges flying out
     - be thankful that the equipment will usually come off worse than you do

Presumably, moving all computer equipment to floor level would reduce the
risks from falling computer equipment, but increase other types of risk
(e.g. tripping over computers, eye-strain).

Ross Anderson  J R A Consulting  ross@jrac.demon.co.uk   (01494) 437030
    Fax: (01494) 537346   <http://www.demon.co.uk/jrac/>

Legal Aspects of Computer Crime mailing list

Martin Minow <minow@apple.com>

Mon, 4 Mar 1996 09:40:37 -0800

In a posting to the Cypherpunks mailing list, Julian Assange
(proff@suburbia.net) announced a mailing list to discuss legal
aspects of computer crime. Based on my reading of the announcement,
it appears to have a UK (or at least English Common Law) focus,
though I suspect that it is not limited to UK-specific issues.
The announcement concludes:

    This list has been created in an attempt to mitigate the lack of
    tangible resources people involved with computer crime have at their
    disposal. It is hoped that by bringing together knowledgeable legal
    professionals together with para-legal personnel and informed lay
    persons that information and resources relevant to the difficult
    task of analyzing, presenting in court, formulating departmental or
    company policy or otherwise dealing with computer crime law and
    computer crimes may be shared and intelligent discussion and law
    reform stimulated.
To subscribe, send mail to:
        lacc-request@suburbia.net
with the body of:
        subscribe lacc
Back issues are available from:
        ftp://suburbia.net/pub/mailinglists/lacc
I haven't looked further but, judging from the well thought-out
announcement (unfortunately too long for a complete posting to Risks),
it should be of interest to many Risks readers.

Martin Minow, minow@apple.com

RISKS of public speaking (Grant, RISKS-17.80)

William Richard Russell <rickr@ruf.rice.edu>

Thu, 29 Feb 1996 17:16:47 -0600 (CST)

jgrant@namsa.nato.int wrote:

> I am not defending Microsoft's products in any way.  I use them because I
> have to and I don't care about which vendor's product is "better" as long as
> the one I have allows me to get the job done effectively.

I think another RISK is that in our eagerness to ridicule the largest
software company in the world, we've forced perfectly sensible people
like jgrant to put needless disclaimers in their discussion of
computer products, for fear of being ridiculed themselves.

Heaven forbid that an end-user should defend Microsoft's products!

Rick Russell // rickr@is.rice.edu //

Typos in RISKS-17.82

Peter G. Neumann <Neumann@CSL.sri.com>

Sat, 02 Mar 1996 07:44:40 -0500

Jot Powers' "Arizona lottery blottery on 29 Jan 1996" had
  >Machines refuse to recognize 29 Feb 1997 (*Arizona Republic*, 1 Mar 1996)
                                       ^^^^
PGN's leap-year item had 1956/1900/1940 instead of 1856/1900/1940.
                         ^^^^
Both were obvious typos, and have been fixed in the archive copy to avoid
further confusion.

Report problems with the web pages to the maintainer