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 19 Issue 02

Wednesday 02 April 1997


o Strange buzzing sound in computer mouse caused by solar wind
Martin Minow
o CalTrain computer stolen -- rider alert
Adrian Brandt via Al Stangenberger
o Another NT security flaw
o Re: The Year 2100 Problem: a simple solution
Mark S. Fineman
o Embedded Chips Suffer from Year 2000 Problem, Too
o Re: Greenwich Mean Time just changed by 1 hour
A. Grant
o Daylight savings time
Andre Sintzoff
o UPS Tracking System experience [name withheld by request]
o Meta-risks of browser flaws
Matthew D. Healy
o Re: SSL Browser Vulnerability Discovered
Eric Rescorla
o Vulnerable Web forms
Anup K. Ghosh
o Re: Risks of automatic spam blockers
Dan Zerkle
o Spam-proofed "From:" lines
Wayne Mesard
o Re: UK Banks' clearing system problem
Jerry Leichter
o Microsoft Typography: Bug or Feature?
Rodger Whitlock
o COMPASS '97 conference agenda
Dolores Wallace
o Info on RISKS (comp.risks)

Strange buzzing sound in computer mouse caused by solar wind

Martin Minow <>
Tue, 1 Apr 1997 14:35:04 -0800
A technically detailed article in the Swedish newspaper, Svenska Dagbladet
(published 1 Apr 1997; explains
that the unusually high levels of cosmic radiation (so-called "solar wind")
augmented by the presence of Comet Hale-Bopp is causing computer problems,
including strange ticking and buzzing sounds that can often be heard if you
hold a computer mouse to your ear.  This is especially true if you first
click on a Java applet.  Svenska Dagbladet's researchers note that (1) solar
wind strengths are unusually high for this time of the year, (2) the near
presence of Comet Hale-Bopp may appear to focus the radiation or,
alternatively, reflect it in a currently unknown manner, says researcher
Torkel Willdmark.  (3) Because it stretches around the world, the Internet
comprises a gigantic antenna that, combined with the increasing number of
digital superhighways, strengthens the signal.  All together, this results
in strange sounds that sometimes sound like extremely soft human speech.

Svenska Dagbladet recommends that web-surfers empty their browser cache
memory frequently to prevent the accumulation of this signal.  This need
only be done for the next few weeks -- until the comet has left the earth's

To determine whether you are affected by this problem, Svenska Dagbladet
recommends that you move your computer's cursor over a Java applet, then
turn off nearby radios and other noise sources.  Then, hold the computer
mouse to your ear: if you are affected by the solar wind problem, you should
hear a soft hiss or buzz from the mouse.  Clicking the mouse while it is to
your ear, making sure that the cursor is over a Java applet, may make the
problem more apparent.

Svenska Dagbladet has a test page (accessible to English speakers) at and a sample of the sound at

Translated and summarized by Martin Minow

  [I note that mouse in Swedish is mus and apple is a"ppel;
  in German, Apple is Apfel, while Apfelmus is applesauce --
  not applemouse.  It mus' be a combination of solar winds and Hale Bopp
  that caused the \344 character for the second letter of Mats Naslund's
  last name in RISKS-19.01 to cause the entire issue to be bounced by a
  bunch of systems unable to deal with 8-bit to 7-bit conversions.
  Let me know if you did not receive your copy and you cannot ftp it.  PGN]

CalTrain computer stolen -- rider alert (Adrian Brandt)

Al Stangenberger <>
Mon, 31 Mar 1997 13:39:48 -0800 (PST)
This isn't a particularly new risk, it's too bad that there is apparently no
way that a credit card could be "partially" deactivated (that is, only valid
if the merchant had the actual card in hand, and that verbal transactions
would be rejected).  What would happen if someone were traveling out of
state and all of a sudden had a dead credit card?..  I've always resisted
having multiple credit cards, but it sounds like maybe it's a good idea.

Date: 31 Mar 1997 19:53:55 GMT
>From: (Adrian Brandt)
Newsgroups: ba.transportation,misc.transport.urban-transit
Subject: CalTrain computer stolen -- rider alert!

CalTrain's ticket-by-mail computer has been stolen.  It contained
credit-card data for customers using credit cards to pay for their
ticket-by-mail.  The computer was stolen out of the ticket-by-mail office
inside of the historic Santa Clara CalTrain station building.

CalTrain spokeswoman Rita Haskin said CalTrain has, through its bank,
initiated account cancellations for all the credit cards in their database.

She expressed some surprise when I told her my credit card worked fine on
the Saturday before Easter.  I've not tried my card since then, but the
clear implication was that she already expected my card to have been
cancelled by that time.

Haskin said that letters of explanation have been sent out to all
ticket-by-mail customers as of Saturday.

I really, really wish that CalTrain had encrypted the credit-card data, or
otherwise taken better care of it--because now I've got to go through the
hassle of getting a new card and contacting other institutions or businesses
I may have made similar "auto-pay" arrangements with...

Adrian Brandt  (408) 565-7291 /

Another NT security flaw

"Peter G. Neumann" <>
Tue, 1 Apr 1997 15:05:10 PST
Bloomberg News reports today (e.g., *San Francisco Chronicle*, C3) that
Windows NT security can be breached.  Jeremy Allison (Cygnus in Sunnyvale)
and Yobie Benjamin (Cambridge Technology Partners in San Mateo) discovered
they can extract passwords.  Microsoft downplayed the discovery, saying the
NT system is ``fundamentally secure''.  MS VP Rich Tong said, ``This is not
a major security hole.''  Details were a bit sparse.

Re: The Year 2100 Problem: a simple solution (Minow, RISKS-19.01)

Mark S. Fineman <>
Tue, 01 Apr 1997 13:06:41 GMT
>  (Recall that the meter was recently changed so that the speed of light is
>  exactly 3,000,000 [should read 300,000,000] meters/second).

Actually, a much cheaper solution than fixing all of software and hardware
is to slow down the Earth's rotation so 1 year is exactly 365 days.
Changing the orbit costs more and messes up the entire solar system, so
changing the length of the day is the best solution.

Embedded Chips Suffer from Year 2000 Problem, Too (Edupage)

Edupage Editors <>
Sun, 30 Mar 1997 13:09:19 -0500
It's not just aging mainframe computers that will go haywire when the clock
strikes midnight on 31 Dec 1999 -- the electronic devices we encounter in
everyday life could have problems, too, according a letter drafted by three
U.S. lawmakers responsible for overseeing public and private sector
responses to the Year 2000 problem.  "Critical systems that depend on
automated devices include security systems for badge readers, surveillance
and home security systems, parking lot gates, and vaults.  Other products
that rely on embedded computer microchips include telephone systems, video
recorders, bar code readers, automatic teller machines, medical devices,
factory machinery, civilian and military avionics, process control and
monitoring equipment, sprinkler systems, and air-conditioning systems."
(BNA Daily Report for Executives 25 Mar 1997; Edupage, 30 March 1997)

Re: Greenwich Mean Time just changed by 1 hour (Wilcoxon, RISKS-19.01)

"A. Grant" <>
Tue, 1 Apr 1997 15:53:08 +0100 (BST) writes:
> On my Linux machines, I keep the hardware clock on Universal time
> to avoid time-zone problems.  One machine is used for both Linux
> and MS Win95, so I set the Win95 time zone to "Greenwich Mean Time".
> At least that's what the map on the Control Panel called it.

Why shouldn't it?  GMT is the correct and current name for British
civil time.  It implies the DST (if selected) will be British Summer
Time.  That is the behaviour I want when selecting GMT in Windows 95.

You don't say what Linux you are running, but Caldera OpenLinux
allows the hardware clock to run local time and strongly recommends

this if the machine is shared with another operating system.

  Al Grant, Cambridge University Computer Lab

Daylight savings time

Andre` Sintzoff <>
Tue, 1 Apr 97 19:37:58 +0200
In the Belgian newspaper Le Soir (, a journalist
related his experience.  Last week-end, he came back from Wales (after a
soccer match).  His plane lands at the Brussels airport. Our friend goes to
the parking lot.  It is 1:58 AM (Sunday morning). He takes his ticket and
puts the money in the machine (entrance of the parking lot), goes to the
exit in his car, puts the ticket into the device to open the gate. But, the
gate doesn't open. Our reporter looks for an employee. They check.  And all
is clear. The device has changed its time.

Explanation: the ticket was paid at 1:58 AM. The reporter tried to exit at
3:05 AM.  And you are not allowed to saty in this parking lot for more than
one hour.

Andr=E9 Sintzoff  Braine-l'Alleud, Belgique

  [At the other end of the spectrum, don't forget Tsotomu Shimomura's tale
  (RISKS-13.28) of being charged $3771 because of a 1992 leap-day glitch.  PGN]

UPS Tracking System experience

<[name withheld by request]>
Tue, 1 Apr 97 13:23:03 PST
I know a businessman who runs a mail-order business.  He claims that for the
first time in over twenty years his mail order business is declining
slightly in a market in which sales are growing -- despite his quite
competitive prices.  He believes his competitors are using the UPS tracking
system to uncover his customers.

Despite not being a computer person, he deciphered the simple checksum
system after some day's thinking about it, and showed me how he is able to
fetch a random package destination of his competitor's in under a minute of
effort.  He is quite angry at UPS, and considered using FexEx to ship his
packages, but found the FedEx system similar enough to enable him to do the
same thing.  He wishes there were a way to force UPS to improve security as
soon as possible.  Meanwhile, he is turning the tables on his competitors by
laboriously retrieving their shipping destinations.  Needless to say, I
declined to automate his efforts.

Meta-risks of browser flaws

Matthew D. Healy <>
Mon, 31 Mar 1997 11:29:03 -0500
I fear the steady stream of news reports about yet another security flaw in
this or that web program may give rise to some severe metarisks; I dunno
which if any of the following possibilities would be most likely:

 o A "boy-who-cried-wolf" reaction -- maybe people will start ignoring
   stories about Yet Another Web Security Flaw.

 o An exaggerated fear of security problems may cause people to give
   up on the Web entirely.  I dunno whether using the Web to buy stuff
   is more or less risky than using older technologies to accomplish
   the same tasks.  I do know that older technologies are far from
   100% perfect; for instance both my wife and my father have had
   their bank accounts hit by check forgers.

 o Those who favor tighter Government control over the Internet may
   use such incidents as "evidence" that the net community can no longer
   be trusted to run something that is rapidly evolving from nifty
   techno-toy to serious communications infrastructure.

 o Overly-rapid attempts to fix the known bugs in what are, by and large,
   kludges that were implemented in a big hurry may produce more and worse
   bugs.  I strongly believe the root cause of most web-related security
   holes is that market pressures pushed developers to concentrate on
   implementing new features quickly, without taking the time to do it right.

The most positive imaginable outcome would be for those who develop web
software to slow down and focus on getting things right; anybody wanna lay
odds on _that_ happening any time soon?

Re: SSL Browser Vulnerability Discovered (Kennedy, RISKS-18.95)

EKR <>
Fri, 28 Mar 1997 17:25:26 -0800
If you have a page that is fetched by SSL GET that has links offsite, then
targets of those links get whatever secure information was passed to the
site over SSL because of the 'Referer' header field.

For example, imagine I'm shopping at LL Bean and I enter my credit card
number on a page and submit it. Then that page has a link to the Wall Street
Journal. The Journal gets my credit card number in the referrer header.

I don't know for sure that this is the problem described here, but it
matches the described facts and I've verified that this problem in fact

There is an interesting variant of this involving inline images
on pages which are fetched with SSL. They get the Referer
header too. Now, there are several ways this can go wrong:

1. GIFs that are pointers to other web sites. E.g. advertising
or the ever-popular numbers used to display the number of hits
on the page. This has the same consequence as described in the
article, that is to say that the site which is referenced
gets the referrer header.

2. GIFs that are pointers to the same web site but are fetched
using HTTP. Navigator seems to forbid this (i.e. it pops up
a warning box and then refuses.) IE pops up a warning box
about loading insecure media (which you might very well not
mind doing) and then proceeds with the fetch. The consequence
of this is obvious: your secret information which you went to
all that trouble to encrypt is now passed over the net in the
clear. In general, all links off an SSL page whose URL+arguments
is sensitive need to be SSL protected themselves.

> ::  Server-side remedies include referring visitors to an in-house dummy
> page to "wipe the browser's feet," or use the POST command instead of GET.
"Wiping the browsers feet" will work, but the dummy page must be fetched
with SSL itself, otherwise you'll just pass that secret information
in the clear when you fetch the dummy page.

> > Users finally, can protect themselves by typing in Internet addresses
> > manually instead of using links from "secure" pages.
As the inline GIF cases above show, this remedy is insufficient.

This seems to be another case of the law of unintended consequences.
Neither SSL nor the Referer header is the problem. It's the
combination of the two that creates it.

Eric Rescorla,  Terisa Systems

Vulnerable Web forms

"Anup K. Ghosh" <>
Fri, 28 Mar 1997 11:00:37 -0500
A risk of using the GET method of the HTTP protocol for sending in
confidential data (such as credit-card numbers) was reported widely
yesterday including on CNET
Warning: this link may be outdated soon.

The article states:

  For users, security risks could arise if they make a purchase at a site
  that uses the GET function to retrieve their credit-card data. Once a user
  has submitted an order and credit-card number, the data is sent to the Web
  vendor in encrypted format. But if the user clicks on a hyperlink to
  another Web site, they could be exposing their unencrypted credit-card data
  to that site.

What is not explained in the article is why credit-card numbers are at risk.
The sum and substance of it is that when the Web site uses the GET method in
a query or form to retrieve your credit-card number, the parameters of the
query are logged in the Web server log files.  Using the POST method does
not appear to log the parameters of a query.  If you are dealing with a
secure site to whom you are sending your credit-card number, sending your
sensitive parameters using either method should be OK---since the data is
encrypted in transit to the site regardless of the method.  You also trust
that site to carefully handle the credit-card number once it is decrypted on
their server.

The problem arises when you jump to another site (that has no business
knowing your credit-card number) after you have submitted your form.
The next site may very well be keeping a record of where you were
"referred" from.  That is, the server logs of the next site will record
the previous site you jumped from before arriving at their Web page.  In
the one popular Web server, the referrer_log file records this
information. For example, using Alta Vista's search engine for "java
security", I found our Web site, then jumped to it.  Looking at the
referrer_log entry below, I find not only the site I jumped from, but
also the parameters of my request.  Alta Vista's query form uses the GET
-> /java-security.html

It is easy to see how filling out one of these forms with sensitive
information like credit-card numbers can be recorded in the next site's
referrer logs.

The risks are obvious.  When using the Web for Internet commerce activities,
people expect that a secure session will protect their credit-card numbers
from unauthorized third parties.  This vulnerability in the GET method
illustrates how this may not be the case.  This risk also illustrates the
lack of privacy in Web surfing.  Not only do you leave your calling card
when you hit a site, you also let the site know where you came from and
potentially any sensitive data you may have submitted to the last site (if
the GET method is used for a form).  Finally, it is important to realize
that even if the POST method is used and a secure protocol layer such as SSL
is employed to protect the data in transit, the data inevitably ends up in
plain text on the Web server's host machine. The privacy of that data is now
only as good as the security of the Web server and scruples of the people
handling the data.

Anup K. Ghosh, Ph.D.
Research Scientist  Reliable Software Technologies Corp., Sterling, VA

Re: Risks of automatic spam blockers (Riddle, RISKS-18.94)

Dan Zerkle <>
Thu, 27 Mar 97 13:44:07 PST
> Dead Bolt allows online users to share their "blacklists" of spam
> purveyors so that they can more effectively filter offending e-mail.

Something like this has, unfortunately, become necessary.  It will happen
someday.  Stopping spam is a topic near and dear to me, and I've already
considered the risks mentioned.

> The risk of false and malicious blacklisting of non-spammers.

This is a serious problem.  A step towards solving it would be a secure
clearing house of data on spammers.  It would need to be distributed via a
technique like PGP-signed Usenet messages or a on online database
downloadable through some secure transfer medium.

Whoever maintained the database would need to somehow decide what went into
it and what didn't.  The entries would have to be classified by reliability
level so that the users could decide which data to use and which to ignore.

Unfortunately, doing this would subject whoever did it to a suit by spammers
who didn't want to be blocked.  I haven't figured out a way to avoid this
particular risk short of establishing the operation in a country without

> The risk of harm to innocent bystanders who happen to share hostnames,
> ISPs, or other characteristics with targeted spammers.

This is not a risk.  This is a benefit.  If users at an ISP get blocked
because the other users at that ISP are spamming, they will take their
business elsewhere.  ISP's will either take measures to avoid harboring
spammers, or they will lose their customers and go out of business.  Either
way, spammers will have one less place to hide.

> The possibility that spam messages will avoid detection by varying return
> addresses and other signatures in each copy of a message.

If the source of a spam can be discovered, this is not a problem.  The
original spamming host is going to show up somewhere in the Received: line,
even if only as an IP number.  Poorly configured sendmails on intermediate
(relay) hosts might not properly include the Received: information.  If this
is the case, the defective site should be blocked until its owners fix it.

Spam-proofed "From:" lines

Wayne Mesard <>
Fri, 28 Mar 1997 10:57:47 -0500
A recent trend in the war against spam is to munge the "From:" line in
outgoing Usenet and e-mail messages (e.g., by adding asterisks or
exclamation points to the beginning or end of the userid).

These messages are typically accompanied by a terse note at the bottom
of the message instructing respondents to "Remove asterisks [or
whatever] from my address if you would like to reply."

I see several risks with this technique:

- False security: Most mail and news agents will dutifully add a
  "Sender:" line containing the "actual" e-mail address, if the
  user-supplied "From:" line doesn't look right.

  Since many spammers already gather addresses from the "Sender:" line,
  munging the "From:" line provides only limited protection.

- Inconsideration: In that a munged "From:" line reduces the spam
  received, it reduces the amount of work the munger has to do.

  So instead of having to press one key to delete a junk e-mail message,
  everyone that wants to reply to one of his messages has to (a) notice
  that the address is bogus (b) press many keys to fix it.  (Indeed, some
  mail readers make it quite tedious to edit the headers in replies.)

  In other words, it hasn't eliminated the problem; it's merely shifted
  the work from the sender to his correspondents.

- Lost messages: a non-scientific survey of some novice-user friends
  indicated that a large number of them had no idea what the "remove
  asterisks..." directive meant, how to perform this task, or what to do
  with the bounced messages that will result from the failure to do so.

- False security 2: In the ever-escalating spam arms race, it won't be
  long before spammers' address-gathering software is modified to
  unmunged munged "From:" lines.  (I can think of two obvious techniques,
  which I won't describe here so as to avoid providing aid and comfort
  to the enemy.)


Re: UK Banks' clearing system problem (Wodehouse, R-18.94)

Jerry Leichter <>
Fri, 28 Mar 97 08:52:31 EST
In RISKS-18.94, Lord Wodehouse reports on the problems some UK banks have
had in clearing pay checks, and speculates on the difficulties this could
cause, especially as it occurred just before a four-day bank holiday.

An article on these kinds of risks appeared in CACM in the mid- to late-70s.
At that time, ATM's and direct deposit were just beginning to appear.  The
authors of the article, as I recall it after all these years, foresaw all of
the problems Mr. Wodehouse mentions.  They speculated on the potential for
much larger-scale problems - "bank blackouts", in which problems in one bank
system would cause overloads, delayed deposits, and ultimately failures at
other bank systems (much as power system problems can propagate to the
systems to which they are connected).

I recall being impressed with the article at the time it was published, and
surprised over the intervening years that so little of what it speculates on
has actually occurred.  Perhaps, as with many technological predictions
about *positive* results of technology, it's not so much that the prediction
is wrong as that the effects it predicts take much longer to arrive than


Microsoft Typography: Bug or Feature? (Sammern, RISKS-18.96)

Rodger Whitlock <>
Tue, 01 Apr 97 09:29:42 -0800
In RISKS-18.96, Thiemo Sammern <> wrote on the subject
"Printing with different resolutions in MS Word 7.0" about documents not
looking the same on 300 dpi and 600 dpi printers and commented on the
Windows API for advance width using rounded integers.

This is a well-known characteristic of Windows typography. Microsoft thinks
it is a feature, judging from posts I have read from MS personnel in the
newsgroup comp.fonts. It does not take multiple printers to see this. Just
set up a spreadsheet with text overflowing a cell boundary and then zoom the
display in and out. You will see the cell border shifting relative to the
text characters.

The risk? Mainly that Windows typography is not "wysiwyg" although one would
naively think so. Some applications manage true wysiwyg, others do not, and
document portability has been sacrificed.

Some applications have smarter typographical guts and avoid this problem. I
believe that WordPerfect is one of them, as long as you use the WP printer
drivers. Various high-end typesetting programs also manage this.

In all fairness, I should add that MS's reasoning is related to their
emphasis on on-screen output. They apparently overlook or don't know that
many people prefer good old-fashioned paper to on-screen display. Perhaps we
see here the risk of one man and his business having far too much power and

Rodger Whitlock

COMPASS '97 conference agenda

Dolores Wallace <>
Tue, 01 Apr 1997 14:34:22 -0500
                                 COMPASS '97
                12th Annual Conference on Computer Assurance
                              June 16-19, 1997
                              Gaithersburg,  MD, USA
                                 WEB SITE

                               Sponsored by
                    IEEE Aerospace & Electronic Society
                        IEEE National Capital Area

COMPASS (COMPuter ASSurance) is an annual conference held in the Washington,
D.C. area with the purpose of bringing together researchers, developers,
integrators, and evaluators interested in problems related to specifying,
building, and certifying high-assurance systems.  What distinguishes COMPASS
is its emphasis on bridging the gap between theory and practice.  The theme
of COMPASS '97, "Are we making any progress toward computer assurance?",
will focus discussion on whether the approaches developed and reported
during the past twenty-five years have any hope for solving today's
assurance problems.  In addition to exploring technical strengths and
weaknesses in the state-of-the-art and state-of-the-practice, conference
goals include: identifying barriers to applying existing assurance
technologies in industry, understanding what properties new technologies
must have to meet industrial needs, and identifying advanced technologies
that are effective in attacking the key problem areas of safety, security,
fault-tolerance, and real-time control.

For researchers, COMPASS '97 provides an opportunity to present new
theories, techniques, methods, or results of case studies to other
researchers and practitioners who can put them to use.  COMPASS '97 also
provides a unique opportunity for participants to learn from practitioners
about issues and problems encountered in constructing practical systems.
This mix of cutting-edge research and practical real-world experience is
unique among software conferences.

Dolores R. Wallace, National Institute of Standards and Technology, NIST NORTH,
Bldg 820, RM 517, Gaithersburg, MD 20899  +1(301)975-3340

  [COMPASS is one of the few conferences that encompasses most of the
  risks requirements -- safety, reliability, security, etc. -- and
  application areas.  PGN]

Please report problems with the web pages to the maintainer