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 20 Issue 28

Thursday 1 April 1999

Contents

o Professor wants Y2K jokes banned on the Net
Edupage Editors
o Daylight Savings Time cutover
Dave Stringer-Calvert
o Y2K: Help for the Weary Programmer
Martin Minow
o IE5 Risk
Lorne Beaton
o The old Ethernet traffic jam in new form
Rob Slade
o More e-mail risks
Silas S. Brown
o Human input error on year causes $49-million error
Frank Carey
o Baby death due to software-controlled air bag deactivation?
Stefan Leue
o Hyperlinks, free accounts, and fraud
Mike Bell
o Melissa beyond denials of service
David Lesher
o Melissa macro virus author tracking
Joe Thompson
o Y2K alert!
Rebecca Mercuri
o Apple Y2K
Dave Stringer-Calvert
o Re: Bringing Y2K fears to a new high -- or low
Gillian Richards
o Re: Great moments in e-mail history?
Jerome H Saltzer
Tom Van Vleck
Jerome H Saltzer
o Laughter causes loop with voice-recognition software
Don Mackie
o Unusable backup power
Tim Kuehn
o "kibibyte" is still ambiguous
D.V. Henkel-Wallace
o Announcement - The Software Engineering Symposium '99
Carol Biesecker
o Info on RISKS (comp.risks)

Professor wants Y2K jokes banned on the Net

Edupage Editors <edupage@franklin.oit.unc.edu>
Thu, 01 Apr 1999 11:25:58 -0500
Insisting that "there's nothing funny about things that aren't funny,"
Professor Wiley T. Langweile of the Palo Alto (CA.)-based Institute of
Internet Reevaluation has written a searing letter to *The New York Times*
(1 Apr 1999) protesting that the American media are so bored with the Year
2000 problem that they're mentioning it only once in every 94.5 sentences
(by the professor's own hand-count).  "Journalists are just not giving
enough publicity to this impending crisis.  They're either ignoring the
problem entirely or making fun of it.  Either way, they're acting
unconscionably.  Y2K irreverence needs to be banned, especially on the
Internet."  Dr. Langweile further charged in his letter that most reporters
fail to include in their stories a detailed explanation of just what exactly
the Y2K problem actually is and what it means to everyday people.  "The low
level of media competence on this issue is just tragic.  Of course, there's
Edupage.  That's the big exception.  Those Gehl and Douglas people really
know how to get to the point of a story, without wasting words.  They're the
only ones I can think of who've successfully explained Y2K in terms of the
big hand and the little hand.  I say God bless them."  (Edupage, 1 Apr 1999)

  [Note to nonGermanophiles: "Langweile" relates to
  Boredom, not Coyotes.  Definitely not the case here.  PGN]


Daylight Savings Time cutover

Dave Stringer-Calvert <dave_sc@csl.sri.com>
Thu, 01 Apr 1999 09:43:11 -0800
Please note the following!

Washington DC (Reuters, 1 April 1999), Roger Tempus, News Staff

In a sweeping move to alleviate the problems generated by the switch to
daylight savings time early on Sunday morning, Congress voted today to
move the switch to Monday.

There has been a long history of confusion surrounding the switch to
daylight savings time, and in a landslide vote this morning members of the
house made a decisive move to make daylight savings a more attractive
option.  This was given wide support amongst the religious groups, concerned
that people would be confused as to the timings of church services this
Easter Sunday.

Congresswoman April Jester (R, CA) confirmed the news this morning and
announced that the changeover will now take place at 10am on Monday morning.
In a dramatic turnabout, the state of Arizona decided that in light of this
decision they too will adopt daylight savings time for 1999.

Wall Street reacted angrily to the news, claiming that the lost hour of
trading may drop the country back into recession.  President Clinton is
expected to sign the order confirming the change this afternoon, claiming
that bedtime is just as, if not more, important than work time.


Y2K: Help for the Weary Programmer

Martin Minow <minow@apple.com>
Wed, 31 Mar 1999 23:02:39 -0800
While reading several articles on the Y2K problem in the 1 April 1999 issue
of RISKS-20-26, I noticed that none addressed the actual problem facing
working programmers: there isn't enough time to finish the job before
December 31.  As we all know from The Mythical Man Month, we can't add more
people to the project: the project will just take longer. What we need is
another month.

I propose Caligua. To honor Roman tradition, this would be added after
August.  This extra month should give us enough time to fix -- and test --
our changes.  While it will cause minor disruption to calendar makers and
astronomers, they, along with all other citizens, will reap the rewards when
the airplanes keep flying on 1 Jan 2000.

And, if we need more time, we can always declare a Saturnalia.

Martin Minow, minow@pobox.com

  [Martin drives a Saturnalias for Caligula.  PGN]


IE5 Risk

Lorne Beaton <lbeaton@MNSi.Net>
Thu, 25 Mar 1999 00:19:49 -0500
Browsing the Web this evening (Thursday, March 24, 1999) using the new IE5
under Windows 98, I click a Favourite to load a well-known tech news site
(http://www.slashdot.org/), then, with the site still loading, immediately
press Control-N to open a new window so that I can load another site as
well. A moment later, I'm a bit puzzled to notice that Slashdot hasn't been
updated since Sunday the 21st. This is particularly puzzling since I had
checked it earlier that day, using my work account, and it was up to date.

My confusion is relieved a moment later, when I notice the site loading up
in the background window (the one that was already open). I have been
looking at the newly-opened window, which appears to have inherited one
piece of state from the previous one (i.e., the URL being displayed) but not
another (i.e., the crucially important fact that the site needs to be
updated, not just redisplayed from the cache).

Contrast this with the behaviour of other web browsers (e.g., Netscape
Communicator 4.51). In a desultory test, Communicator acted correctly (i.e.,
displayed up-to-date information in a new client window, even as the
previous window was still reloading the site). This was done with
Communicator set to load "Last page visited" when opening new client
windows. It appears that Communicator 4.51 checks this setting each time a
new client window is opened, whereas IE5 checks this setting only once, when
launched. There also appears to be no way to change this behaviour.

Possible risk (which I have not noticed in previous versions of IE, although
it may be present there as well) is that a less-observant or more naive user
might assume the outdated information is actually up-to-date and correct.

Lorne Beaton <lbeaton@mnsi.net>


The old Ethernet traffic jam in new form

Rob Slade <rslade@sprint.ca>
Tue, 23 Mar 1999 14:35:48 -0800
I am currently trying to download something from Microsoft--for the eleventh
and twelfth time in the past five days.

The problem, of course, is probably the recent announcement of IE5.
Everybody and his or her dog is trying to download the latest and buggiest
browser.  (Bob Frankston's problem with his bank is only one of many: Visual
Studio 6 and Eudora Pro both have problems with it, and then there is the
AutoComplete function ...)

However, I am inescapably reminded of the old problem with Ethernet, and
Carrier Sense Multiple Access with Collision Detect.  As traffic rises
collisions grow more common.  Therefore, there are more retries on the net,
and therefore traffic rises and ...  (Anyone who has to commute over a busy
bridge knows why network traffic analysis is called "traffic" analysis.)
Same thing is probably happening here.  More people are trying to download
the files from Microsoft.  Therefore, more downloads fail, therefore more
people try again, therefore ...

Yes, I'm contributing to the problem: I'm running two separate downloads in
the hopes that one will finally succeed.  Probably a lot of net-savvy people
are doing the same thing, or better (worse?)

Completely beside the point, the program I am trying to download is the new
version of MediaPlayer.  On Friday it was a 4.8 meg file.  Today the same file
is 3.4 meg. One of the never-to-be-known mysteries of the net, I guess ...

rslade@vcn.bc.ca  rslade@sprint.ca  robertslade@usa.net  p1@canada.com


More e-mail risks

"Silas S. Brown" <ssb22@cam.ac.uk>
Mon, 22 Mar 1999 08:11:20 +0000
> Once again we are reminded of the incredible variety of risks of e-mail.

Here's a really strange one: Ever heard of PostPet?  It's a Japanese
computer game that's also an e-mail client.  Besides limited capability to
deal with normal mail, you can send your "pet" with the message to another
PostPet user.  Your pet gets sent as an attachment and returned immediately
upon delivery with updated status (depending on how your friend treats your
pet etc); there is a timeout.  (It gets returned in a "Secret Diary" message
supposedly written by the pet; the language of this diary depends on that of
the destination client.)  Pet mail also causes the addition of the sender to
the recipient's list of friends.

Risks:

1.  If too many people use this thing, we may get spamming incidents in
which the spammer adds a PostPet attachment to the spam, thus ensuring a
personalised delivery, a guaranteed response from valid addresses and an
addition to people's personal contact lists.

2.  The file format of the attachment can be reverse-engineered, and a
response generated artificially, for any social purpose whatsoever.  In
fact, once someone has sent you their pet, you can keep its ID for use later
- all you have to do at any time is send a message with a custom status and
arrange for it to arrive while the pet is "out".

3.  There is no way of viewing full headers, and hence if someone is
abused etc they can't report it.  (Many other things can't be done, too.)

4.  Games aren't really meant to live in the application world.  If they
ported it to Unix, it could consume vast amounts of CPU on a shared system
and equally vast amounts of network bandwidth updating the display.

5.  The buttons for "send pet" and "send normal e-mail" are far too close.

6.  This is no way to introduce e-mail to people new to computers, and yet it
is (apparently) being used for that in Japan.  This could lead to people not
learning things properly.  The PostPet documentation is full of metaphors
that don't really tell you what's going on.

7.  It generally increases the amount of pointless e-mail and wasted time.

-- Silas S Brown, St John's College Cambridge UK http://epona.ucam.org/~ssb22/


Human input error on year causes $49-million error

Frank Carey <carey@voicenet.com>
Mon, 22 Mar 1999 09:45:53 -0500
On 21 Mar 1999, 180,000 families in New Jersey receiving food-stamps took
advantage of an error by which their April credits were enabled 10 days
early.  In the 15 hours until the problem was discovered and fixed, the word
spread rapidly and shoppers went on a feeding frenzy.  Many stores ran out
of staples (food, not metallic).  A state employee was preparing for the 1
Apr 1999 crediting of food-stamp accounts; discovering that performance was
dragging seriously, he off-loaded the processing onto the backup mainframe,
and then moved the resulting files back to the main system.  Initial blame
was placed on a recent Y2K upgrade, but later reports observed that he had
input "199" instead of "1999" in making the cutover, and the program coerced
a zero on the end to make the year "1990".  So, perhaps the problem was
indirectly Y2K-related after all.  [Source: *The New York Times* 22 Mar
1999, p. B1; *Newark Star Ledger* 22 Mar 1999, p. 13, with revisions to
absolve Y2K two days later, *NYT* 24 Mar, B5.  PGN-ed, starkly]


Baby death due to software-controlled air bag deactivation?

Stefan Leue <sleue@fee.uwaterloo.ca>
Mon, 29 Mar 1999 23:54:00 -0500 (EST)
Under the headline "Vom Retter erschlagen" (`Slain by the Savior') the
German weekly "Der Spiegel" (http://www.spiegel.de) reports on page 226 in
its issue 12/1999 on the analysis of an accident in which a baby sitting in
a rear facing car seat mounted to the front seat in a Volkswagen Golf was
killed by the impact of the deploying air bag in an oncoming traffic
collision. The car owners and parents of the killed baby had previously had
the air bag disabled in a certified garage.

The wreck of the car is currently sealed by the public prosecutor's office
and inaccessible to Volkswagen and the manufacturer of the air bag
electronics, Siemens. Volkswagen maintains that the deployment of the air
bag may either have been caused by a voltage surge in the car's electronic
system resulting from the impact on the battery, or by electrostatic
discharges.

Experts from the Technical University of Munich, working for the public
prosecutor's office, consider these explanations implausible and target a
systems engineering fault as a more likely causal factor. Deactivation of
the airbag in a Golf is a software-controlled function, as opposed to other
manufacturers who physically disconnect the air bag from the board
electronics for deactivation. As physical circumstances in a car
(temperature variations, moisture, vibrations) form a fairly hostile
environment for the air bag control hardware, the software system running
inside the control performs ongoing self checks using checksum
algorithms. If an error has been detected, the current software settings,
including the data responsible for the deactivation, will be replaced by
backup software read out of a read-only memory. The backup software,
however, only knows a simple set of rules, namely that all air bags in the
car will be deployed upon impact. Evidently, the backup software is unware
of a previous software-controlled deactivation.

Stefan Leue


Hyperlinks, free accounts, and fraud

Mike Bell <mbell@albionresearch.com>
Mon, 22 Mar 1999 09:28:18 -0500
SPAM-L this week contained a description of interesting method being
used to obtain credit-card numbers.

1. Grab e-mail addresses of AOL users in chat rooms.
2. Mail them a forged message from AOL asking them to click on a hyperlink
   to verify their billing details. "Click here" takes them to a
   forged AOL page on a free web service asking for exact credit card
   details, passwords, etc.
3. If they fill out the form, it is POSTed to an innocent cgi script on
   another site which accepts a hidden argument specifying an e-mail address
   where the credit card information will be mailed to.
4. Finally the cgi script redirects the user to a third throw-away site
   ("Thank you for changing your account details").
5. The perpetrator can now pick up a list of credit card numbers from
   the free e-mail account from anywhere in the world.

The basic risk here is an old one: clicking on a hyperlink may not always
take you where you think. In addition the use of free anonymous e-mail
accounts and web pages makes it far easier for the criminal to avoid a
simple paper trail.

-- Mike --


Melissa beyond denials of service

David Lesher <wb8foz@nrk.com>
Thu, 1 Apr 1999 13:37:47 -0500 (EST)
One thing only a fraction of the popular press coverage has touched upon is
that: while spreading itself around the world, Melissa also appears to send
the document the victim is dealing with at the time as well.

THAT may have consequences that last far past the Denial of Service
logjam. If the file in Word was confidential and Melissa leaks [..you name
it..] out....

This might draw some attention to other Word problems; such as its
propensity to send along both deleted text as well as that from other
document windows. It does not show when rendered by Word, but it's still
there....

(A friend at a Fortune 500 communications company recently was sent a doc
whose distribution was limited to 5 or 6 people. He used the Unix tool
'catdoc' to read it on his workstation & discovered most of an innocuous 2nd
doc also in the file. "Suppose it had been the other way around?" he
remarked.)

Such covert channels have always been a concern some people paid serious
attention to [witness IntelLink's physically separate networks for U, S, and
TS/SCI; and the recent release of AES material via printer-->scanner-->PDF
route]; I hope more people will now do likewise...


Melissa macro virus author tracking

Joe Thompson <fbi.gov@orion-com.com>
Thu, 01 Apr 1999 01:25:02 -0500
As it turns out, the GUID is *not* a reliable identifier of the author for
the Melissa virus:

http://www.zdnet.com/zdnn/stories/news/0,4586,2234018,00.html

Synopsis: If a Word document is passed to another person, modified, and
saved, the original GUID is preserved even though none of the actual content
may still be extant.  In this case, the GUID in question has been discovered
in works from other authors.  The person currently under the most suspicion
(known as VicodinES) says that the virus code in his document that has the
same GUID as Melissa (a macro virus named PSD2000.DOC) is actually based on
earlier virus code from another author (known as ALT-F11); indeed, the GUID
on that earlier work *also* matches Melissa.  So does the GUID on other work
by ALT-F11, while work that VicodinES claims is original with him does *not*
have the Melissa GUID.  *Anyone* could have written Melissa and made
VicodinES, or any other Word user they want, appear to be the culprit.

Here we see the inherent RISK of relying on a non-unique identifier; in
this case, the fact that the ID is inherited poses additional risks of
misidentification. -- Joe

Joe Thompson  http://kensey.home.mindspring.com/  fbi.gov@orion-com.com

  [Even if they are unique, such IDs may be easily forged.
  Once again, the use of digital evidence is tricky.  PGN]


Y2K alert!

Rebecca Mercuri <mercuri@gradient.cis.upenn.edu>
Thu, 18 Mar 1999 00:20:00 -0500 (EST)
--- Forwarded mail from a colleague at Disney ---
FINALLY! A Programmers Drinking Song! Woo! Hoo!

  PROGRAMMERS DRINKING SONG:

  99 little bugs in the code,
  99 bugs in the code,
  fix one bug, compile it again,
  101 little bugs in the code.
  101 little bugs in the code.....
    (Repeat until BUGS = 0)

  [I think it's appropriate, given the rash of "buggy" animations these days.
  Rebecca.]  [It's nice that Y2K is also brewing lyrics.  PGN]


Apple Y2K

Dave Stringer-Calvert <dave_sc@csl.sri.com>
Wed, 17 Mar 1999 22:23:46 -0800
This is cute:

>                 "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


Re: Bringing Y2K fears to a new high -- or low (Gerlek, RISKS-20.24)

"Gillian Richards (02) 4780 3513" <gillian.richards@tafensw.edu.au>
Wed, 17 Mar 1999 13:47:42 +1100
>   [...]  We don't want people going and buying
>   generators when they should be out buying jeans."

There's another *hidden* problem.  In Australia, the most common brand of
zippers (zip-fasteners) used on manufactured clothing is YKK.

I have no idea what sort of compliancy tests to run on my zippers, and,
wishing to take *no* risks of the "system" being down at the wrong time,
will be wearing either buttons or elastic on 31 December 1999.

Gillian Richards, Computer Systems Officer  <gillian.richards@tafensw.edu.au>
Wenworth Falls TAFE Campus, NSW Australia


Re: Great moments in e-mail history? (Neugent, RISKS-2.25)

Jerome H Saltzer <Saltzer@MIT.EDU>
Mon, 22 Mar 1999 23:06:17 -0500
Part of the problem is that the definition of e-mail is a bit fuzzy.  If you
define it to mean any mail-like electronic message, then you can trace it
back to 1851, when the New York and Mississippi Valley Printing Telegraph
Company (predecessor of Western Union) began sending telegrams.  The AUTODIN
messaging system may belong in that family tree.

If you mean mail-like messages between computer users, then CTSS certainly
had a mail command that may be a candidate for first.  If Corby [Corbato]
searches his attic, he might be able to find a date earlier than the circa
January 1965 PSN you identified.  A survey of the other time-sharing systems
of the time would probably turn up some other mail programs.

But that didn't go between machines.  If e-mail means that two computers
have to be involved, then Kleinrock may well have sent the first piece of
e-mail that crossed the net.  I don't recall that we ever had mail moving
between the two CTSS machines (MAC and Computation Center) at MIT.

Jerry


Re: Great moments in e-mail history? (Neugent, RISKS-20.25)

Tom Van Vleck <thvv@multicians.org>
Mon, 22 Mar 1999 23:01:57 -0800
AUTODIN probably counts as one of the "first" e-mail systems.  As I remember,
there was a BBN project called "Mercury" that was also working on electronic
mail.  Noel Morris and I knew that both of these existed when we wrote CTSS
MAIL, but were not sure whether Mercury was ever deployed.

PSN 40 _proposed_ a MAIL command.  As I remember, Noel and I, junior
energetic programmers, offered to do it while others were busy with Multics
design, and were given permission.  When I visited Roger Roach about 8 years
ago, he still had the CTSS source, and I looked at the source of MAIL, and
it was my code.  It had Dick Mills's, Bill Bierstadt's, and my programmer
numbers baked into the code.  We, and M1416 * could send messages to all
users.  (See my story, quoted in _Wired_, about the first spam, sent by
Peter Bos.  Remember that? He abused his system programmer privilege to send
a message beginning THERE IS NO WAY TO PEACE. PEACE IS THE WAY.  When I
remonstrated, he said, "But this is *important.* Wired got my name wrong.
Peter Bos and Noel are both gone.)

>...  If e-mail means that two computers have to be involved, ...

That definition would of course depend on the meaning of "computer."  Would
Tandem's multi-node, multi-CPU, single-system-image MAIL qualify?  In some
senses that system was a 645 with very long buses.  Was it one computer or
many?  Was the 645?


Re: Great moments in e-mail history? (Van Vleck, RISKS-20.28)

Jerome H Saltzer <Saltzer@MIT.EDU>
Tue, 23 Mar 1999 09:32:10 -0500
Here is another try at imposing categories and milestones on what looks more
and more like continuous evolution:

1.  First mail-like communication by electronic means (telegrams): 1851,
Mississippi Valley Printing Telegraph Company.

2.  First interposition of computers in handling mail-like communication:
perhaps 1957, TELEX, and probably also some predecessors of AUTODIN.

3.  First mail-like communication within a system used for general-purpose
computing: early 1960's, Van Vleck & Morris on CTSS or perhaps BBN Project
Mercury.

4.  First mail-like communication between two computers operated by
different administrative entities: late 1960's, perhaps Kleinrock's
anecdote, but it needs some more research.

Lenny Kleinrock can probably claim without fear of contradiction that he
sent the first e-mail over the ARPANET, because he was standing at one end
of the first ARPANET link that was installed.  The fact that Kleinrock's
anecdote is dated at practically the instant of that installation is pretty
compelling evidence that e-mail was already well-known and operating within
individual time-sharing systems.

Jerry


Laughter causes loop with voice-recognition software

Don Mackie <donald@iconz.co.nz>
Sat, 13 Mar 99 16:41:39 +1300
My son has dyslexia.  To help him deal with life, he has some
voice-recognition software on his PC.  In the early stages of training he
found that odd noises, such as laughter, were interpreted by the computer
and, at best, produced long strings of random words.  Having a normal
teenager's sense of humour he found these funny, laughed some more and so
on.  When his giggles subsided he had to utter the command "delete last four
pages".  I now recognise the signs of mirth in his e-mails.

Even funnier is getting the computer to read back the laughter passages.


Unusable backup power (Re: Weingart, RISKS-20.24)

Tim Kuehn <timk@tdkcs.waterloo.on.ca>
Mon, 22 Mar 1999 10:01:40 -0500
> ...  It's not enough to have a backup system in place...you need to make
> sure it will work when needed.

... and that if it's there you're able to or allowed to connect to it.

A colleague maintains a number of Internet Web servers as a commercial
venture.  Friday he found out that the building that houses these servers
was going to be disconnected from the power mains for 8 hours starting at
midnight Saturday in order to conduct an annual power audit.

The company he was renting space from didn't have enough capacity in their
battery backup systems to run his equipment, but would have the system
upgraded "next month." The room is sealed, so putting in a small
internal-combustion driven generator was out. There is a diesel-powered grid
in place, but it only generates 48V DC used by a number of telco switches in
the room. And trying to find a sufficiently sized 48VDC to 110VAC inverter
for rent was an exercise in futility.  A number of vendors were more than
willing to sell him one of these ~$4K devices however.

The risk here is that even if backup power's available, you may not be able
or allowed to use it.

Tim Kuehn


"kibibyte" is still ambiguous (Re: Edupage, RISKS-20.25)

"D.V. Henkel-Wallace" <gumby@zembu.com>
Mon, 29 Mar 1999 18:30:56 -0800
  The new term "kibibyte" will more accurately describe the number of
  bytes in a kilobyte -- rather than being 1,000, as could be
  inferred by the prefix "kilo," a kilobyte actually has 1,024 (2 to
  the 10th power) bytes.

Has the 8-bit usage of the term "byte" been internationally standardized?
Or is "kibibyte" still ambiguous (for Multics and PDP-10 hackers at least)?

"Kibioctets" anyone?  Sounds like a cat food.

David Henkel-Wallace, Zembu Labs


Announcement - The Software Engineering Symposium '99

Carol Biesecker <cb@SEI.CMU.EDU>
27 Mar 1999 22:08:30 GMT
The Software Engineering Symposium '99
Theme: Improving the State of Software Engineering:
  Principles, Practices, and Projections

August 30--September 2, 1999
David L. Lawrence Convention Center
Pittsburgh, Pennsylvania

Early Bird Registration: July 28, 1999

For the most up-to-date information, bookmark our Web site at
http://www.sei.cmu.edu/products/events/symp/
or contact

Symposium '99 Conference Coordinator
Software Engineering Institute
Carnegie Mellon University
Pittsburgh, PA 15213-3890
Phone: 412 / 268-3007
FAX: 412 / 268-5556
E-mail: symposium@sei.cmu.edu

Please report problems with the web pages to the maintainer

Top