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 42

Friday 24 October 1997

Contents

o San Francisco blackout
PGN
o Modern cars
Phil Scott via Adam Cobb and Paul Saffo
o Screen saver dogs DoD's Common Operating Environment
John Long
o The risk of "zero defects"
Peter Kaiser
o When taking a guess isn't so smart
Dominic J. Hulewicz
o Risks of Civic Virtue
Peter Wayner
o Risks of debit cards for merchants
Benoit Lavigne
o Re: Another way to exploit local classes in Java
Li Gong
o Re: Internet sting identifies 1,500 suspected child pornographers
Mike Perry
o Re: Paris police computer spares Corsican motorists
Clive D.W. Feather
o 911 silence similar to former Lexus problem
Ari Rapkin
o Costs and benefits of war-dialing
Mich Kabay
o Problems with ACM e-mail forwarding service
David Sedlock
o Re: IE4, Netscape, and font anti-aliasing
Bryan O'Sullivan
o NCSA CyberRisk 97 Conference
Mich Kabay
o Info on RISKS (comp.risks)

San Francisco blackout

"Peter G. Neumann" <neumann@csl.sri.com>
Fri, 24 Oct 97 9:52:56 PDT
126,000 customers in northern San Francisco experienced a power outage for
up to 3.5 hours beginning at 6:15 a.m. on 23 October 1997, when five
transformers stopped working at the power substation at Eighth and Mission.
The FBI counterterrorism unit is investigating what it considers the
likelihood of sabotage (for reasons not revealed, although 39 of the 42
switches were open).

  [If this turns out to have been not terrorism but rather salt water spray
  from the San Francisco Bay accidentally causing a short that tripped the
  switches, we would have a new interpretation of "Bay to Breakers" (the
  annual so-called San Francisco foot-race).  PGN]

    [Error in date (23 Oct) corrected in archive copy.  PGN]


Modern cars

"Paul Saffo" <psaffo@iftf.org>
17 Oct 1997 22:04:58 U
  [This just came into my mailbox.  I have no idea if it is for real, or is
  a spoof.  In the absence of further indicia of truth, I am inclined to put
  it into the urban legend category.  Paul]

Date: 10/15/97 05:50 PM
>From: acobb@coombs.anu.edu.au
Hi everyone
from a colleague
It's about new fancy electronic car failures due to electromagnetic fields

>Morning all,
>Thought that this article in the Sydney Morning Herald, Monday, Oct 13,
>pp.1 and 4 would be of interest.
>Tim.
>
>*********************
>"Crazy cars:  the newest hazard on Sydney's roads"
> Phil Scott, Motoring Editor
>
>New cars are jamming their own brakes, locking doors, shifting gears and
>mysteriously shutting down.  The cause: electromagnetic interference, the
>same phenomenon that affects hospital equipment and aircraft instruments.
>
>At risk are a small number of new cars with inadequate "immunity" built
>into the electronic systems which control engines, brakes, transmissions
>and features such as central door-locking, cruise control and
>air-conditioning.  Some airbags, claim the experts, may even be prone to
>random firing.
>
>Engineers list known Sydney hot-spots as near the airport on General Holmes
>Drive, in parts of Chatswood and Hurstville.  Traffic light sensors, taxi
>and police radios, broadcast transmitters and underground power lines can
>trigger failures.
>
>Volvo has a unique problem at Tempre, where power lines under the Prince['?]s
>Highway have caused brake pedals to pulsate opn five examples of its
>flagship 9-Series models.
>
>"The power lines are buried in the kerbside lane and have caused the
>braking system to pulse if the car is stationary" a Volvo spokesman, Mr.
>Graeme Adam, said last night.
>
>Also affected is Hyundai.  "We've had a number of instances but you can
>count them on two hands", said Mr. Patrick Lyons, public affairs manager.
>Some of the company's Lantra models were shutting off their anti-lock brake
>systems, leaving drivers with mechanical brakes and a red warning light.
>
>Volvos with jammed brakes, Ford door locks which open and close unaided and
>Holden glitches with air-conditioning and automatic transmissions are being
>attributed to interference.
>
>Australia, unlike Europe, has no design rules requiring common standards of
>"immunity" for electrical systems in cars.
>
>The technical director of  the accredited testing authority EMC
>Technologies, Mr Chris Zombalas, said: "This highlights a critical safety
>issue and the problem, to put it mildly, is poor engineering.  The
>electronic systems aren't engineered properly to operate in the
>environment".  Automotive failures are also well-known to RFI Industries,
>an independent testing laboratory in Melbourne.
>
>"Of course the automotive world is closed-mouthed, like the medical world",
>said Mr Dick Davies, manager of its electro-magnetic compatibility and
>interference laboratories.  "We put these malfunctions into different
>classes
>
>"A fuel gauge that doesn't work when you're on the mobile phone is a grade
>one.  A grade two might be the windshield wipers going off.  Startling,
>yes, but by itself unlikely to cause an accident.
>
>"Grade three could be the electric seat repositioning itself while you're
>driving.  That could, perhaps cause an accident.  Then you have grade
>fives, the catastrophic ones.  You might be driving down the Hume Highway
>at 120km/h and the microprocessor says stop the left wheel...or maybe the
>cruise control jams".
>
>Mr Davies cites an incident near Sydney airport.  "An underground power
>cable was run out in the airport extensions under the freeway.  It just
>happened the car was moving very slowly in a traffic jam and it sensed the
>magnetic field from the cable, and stopped the front wheels.  It was kind
>of embarrassing.  The sensors, depending on the brake system, can be
>magnetic and the frequency of the mains cable was just the right frequency
>to set off the brakes."

Adam Cobb, Research School of Pacific and Asian Studies, Australian National
University ACT 0200 Australia  61-2-62438557 http://coombs.anu.edu.au/~acobb


Screen saver dogs DoD's Common Operating Environment

John Long <johnlong@ix.netcom.com>
Tue, 21 Oct 1997 14:55:38 -0400
The DoD has creating a standard operating environment called the Common
Operating Environment.  All internal and external development is expected to
comply with the COE.  However, recently, it was discovered that there was a
bug in the screen lock program that came with it:

> I have discovered that the screen saver used when the COE screen gets
> locked, somehow always "the worms", consumes all available cpu time on the
> system. This causes any boot processes of the application, and even
> graphical application processes the user is running, to slow to almost
> zero progress any time the screen gets locked. I first discovered this when
> I walked away from a system running the COE segment installer. The screen
> locked, as expected by the deadman timer. When I unlocked it, though, I
> discovered that no progress had been made on the segment install.
>
> While this problem is just an inconvenience in the case of segment
> installs, this is catastrophic for the application my customer is
> migrating. This application includes a number of boot processes that
> maintain a constant flow of data between each of the machines running this
> application. There is no room for falling behind just because the screen
> saver is displayed.

Apparently the screen saver, probably considered as a utility, was not
tested with the rest of the system when it was integrated.  Thus, the
general risk is one of creating a seemingly innocent function, adding it to
a product, and having a severe impact.

John Long Castek  RBG - The Reuse Business Group johnlong@castek-rbg.com


The Risk of "zero defects"

Peter Kaiser <kaiser@acm.org>
Mon, 20 Oct 1997 09:40:05 +0200
I recently visited a Web page that contains this:

    * Cleanroom Software Engineering
      The objective of the Cleanroom methodology is to achieve or
      approach zero software defects with certified reliability.

where the heading line was a link.  I clicked it, and got a page whose
entire contents were:

    Error opening file:

So I wrote to the webmaster, who eventually responded that the problem had
been corrected.  I tried the link again.  It hadn't.  Perhaps by now it has
been, but I'm in no hurry to go back there.

I'd be cautious in putting a page up about "zero software defects" -- there
may be some Goedelian rule operating in the universe of software under which
any software complex enough to be useful must necessarily contain at least
one defect.  In "The Psychology of Computer Programming", still a good read,
Gerald Weinberg recounts a lovely story about debugging the null program.
As you might guess, even the null program could contain bugs.

Pete   kaiser@acm.org


When taking a guess isn't so smart

<dom@inta.net>
Thu, 23 Oct 1997 17:03:22 +0100 (BST)
Having in the past given up with the domain name private.org due to
the amount of irrelevant e-mail I received to it, you would have
thought I would know better.

I own the domain name HTTP.ORG. The web site for that domain has
always received a fair amount of seemingly random hits, presumably
from people mistyping URLs and having their domain suffix search
order including ORG.

Recently however I have noticed a dramatic increase in the number
of hits to www.http.org, so I decided to investigate further. Looking
at the access logs, it did appear that the recent upsurge in hits
could also attributed to mistypes. But why the very recent increase ?
The common link is Lynx web browser 2.7.1.

It would appear that the latest version of Lynx likes to pretend to
be clever and guesses at a URL if it doesn't receive a response from
the host that you typed. Unfortunately this means that a request for
any of the following typos:

  lynx http//:www.somedomain.com
  lynx http//www.somedomain.com
  lynx http/:www.somedomain.com
  lynx http/www.somedomain.com

Will result in Lynx trying...

  Looking up 'http' first.
  Looking up 'www.http.com', guessing...
  Looking up 'www.http.edu', guessing...
  Looking up 'www.http.net', guessing...
  Looking up 'www.http.org', guessing...
  Getting http://www.http.org//www.somedomain.com

At which point my site is queried.

The risks are obvious. Confusion reigns and I receive a constant flow of
hate e-mail from users all around the world who think that I have hijacked
the web sites they are trying to reach. *sigh*

Dominic J. Hulewicz - mailto:dom@inta.net - http://www.intanet.com/dom

  [Dominic CC:ed a lynx development list on this contribution.
  I have carefully removed that address here, but am now getting
  copied on requests to be removed from that list!  I never sausage lynx
  before.  PGN]


Risks of Civic Virtue

Peter Wayner <pcw@access.digex.net>
Fri, 24 Oct 1997 09:59:15 -0400 (EDT)
I paid *too* much in taxes and got labeled a deadbeat taxpayer.  Here are the
four components for disaster: 1) my mortgage holder pays my property taxes,
2) I'm enrolled in a special program that lowers the amount kept in escrow
because I pay these taxes semi-annually instead of annually, 3) most people
pay annually, 4) computers.

The mortgage company, for some bizarre reason, paid too much in taxes. It
turns out they paid the 3% fee for using the semi-annual scheme with the
first half instead of the second half. The city's computers saw that the
amount was more than was owed semi-annually and assumed I was voluntarily
trying to pay annually. It kindly switched me over to the annual plan. But
since the amount was also less than the annual amount, it assumed I was a
tax cheat.

If I didn't catch this, the house would have been auctioned off.


Risks of debit cards for merchants

Benoit Lavigne <blavigne@ca.newbridge.com>
Mon, 20 Oct 1997 14:55:30 -0400 (EDT)
I heard the following story on CBC Radio 1:

A picture framing business had more than 240,000$ stolen from their account.

A quick debit card primer
The debit machine is normally used by the merchant who swipes the client card
in the card reader, then enters the amount of the sale.  The customer then
enters his PIN on a separate keypad.  When the PIN is verified, the customer's
bank account is debited and the merchant's bank account is credited.
A transaction adjustment is the reverse.  The process is the same, but the
customer's account is credited and the merchant's is debited.  This is a
relatively rare transaction (typically used when returning an item which
was purchased via debit card).

The story:
On Friday Night, thieves forced the front door open with a crowbar, and
used the merchant's debit machine (which is also used to charge Visa & MC)
to do transaction adjustment in excess of 240,000$.  They used 10 debit
cards for which they had the PIN numbers. When the merchants opened their
store on Monday, nothing had been stolen and they did business as usual.
Only when they did the "debit machine reconcile" at the end of the day did
they notice a discrepancy.  The balance from the debit machine slip read
-248,372$.  Fearing a mix-up, or some data entry SNAFU, they contacted the
bank, but no one returned their call.

The next day, their account had been frozen, and their vendor number (used
to process MC & Visa) was suspended.  All this time, no bank officials would
return their calls. Eventually, they reached someone in the corporate office
who told them that they couldn't do anything until the police investigate.
The police determined that thieves did the deed by Thursday, but the bank
still took over 2 weeks to reinstate the account and vendor number.

Some interesting points:
  - The transactions were done between Midnight and 4 AM.
  - There was a $45,000 adjustment done at 3AM.
  - The bank account balance at the time was only 2000$
  - The merchants DID NOT have overdraft protection.
  - In order to start a debit machine, one needs a special vendor card.
    But the bank typically tells customers to keep the card in the cash
    register till for easy access.
  - The merchants have been doing business with the same bank for over
    18 Years.

The thieves have been identified.  It mystifies me how they thought they
could get away with it, since the transactions are traceable.

Some thoughts:
  On the bank side, there doesn't seem to be any checks made on the validity
  of a transaction adjustment (Unusual transaction patterns, overdraft, etc).
  No one at the bank seemed to know the system, or be able to give answers.

Plenty of familiar risks:
  - No transaction validation
  - Not securing the key card
  - Clue-less bank advice
  - Clue-less bank officials

Benoit


Re: Another way to exploit local classes in Java (RISKS-19.41)

Li Gong <gong@games.Eng.Sun.COM>
Fri, 17 Oct 1997 19:35:27 -0700
Andre L. Dos Santos (RISKS-19.41) described an attack based on
installing classes onto CLASSPATH.  "The danger of setting the CLASSPATH
environment variable to a path where malicious classes are located is well
known."

Starting from JDK1.2 (public beta version should have appeared on our web
site by the time this article appears), we can separate from locally stored
system code and locally stored but less trustworthy code.  In particular,
a separate class path (configured using a Java property) is introduced such
that

  (1) CLASSPATH should only contain trusted system code (so in most
      cases, a user should not touch/change it);

  (2) java.app.class.path should contain everything else one wants to
      load from the local file system.

Local applications loaded from java.app.class.path are subject to the same
rigorous bytecode verification and other runtime checks that have been
applied to applets downloaded over a network.

In short, there is no longer any built-in difference (in terms of security)
between a local application and a remote applet.  Moreover, a policy-based,
easily configurable and extensible security model is now applied, equally,
to both applets and applications.  (Documentation of this should come with
the beta release.)

Li Gong, JavaSoft, Sun Microsystems, Inc.


Re: Internet sting identifies 1,500 suspected child pornographers

<Mike_Perry@DGE.ceo.dg.com>
Wed, 1 Oct 1997 20:22:56 est
(Re: Youngman, RISKS-19.40)

It's interesting to note that this operation would not have been hampered
one bit by strong encryption - even if the images were so encrypted, the
sting would have obtained the keys - there's no point mailing an encrypted
image to someone you think is a fellow devotee without the key....

Also, the site (http://www.cnn.com/US/9709/30/cybersting/) shows
again a worrying lack of understanding amongst lawmakers/enforcers.

It took "investigator Michael McCartney" (they don't say which agency) 10
minutes using e-mail to get "a picture of an adult male having sex with an
adult male".  Hasn't he heard of Usenet? - I'm sure that it wouldn't have
taken that long to find something in a.b.p.e.gaymen.

Mike


Re: Paris police computer spares Corsican motorists (Boggio, R-19.41)

"Clive D.W. Feather" <clive@demon.net>
Sat, 18 Oct 1997 09:28:27 +0100
Actually, there's a slight translation problem here. France is divided into
96 "Departments", corresponding roughly to counties. These were initially
numbered 01 to 95, so if you live in number 42, your car registration is of
the form "NNNN XX 42" (say "2724 TJ 42") and your postcode is of the form
42NNN (say 42301).

Then Corsica - number 20 - was split into two Departments, numbered 2A and
2B (and not to be confused with 02). So cars are now 2724 TJ 2A, but
postcodes remain 20123.

Clive D.W. Feather, Director of Software Development, Demon Internet Ltd.
Tel: +44 181 371 1138   Fax: +44 181 371 1037 <clive@demon.net>


911 silence similar to former Lexus problem (Wilcoxon, RISKS-19.41)

Ari Rapkin <ari@HOSTESS.GRAPHICS.CS.CMU.EDU>
Thu, 23 Oct 97 10:19:21 EDT
I wonder whether they will add artificial "line-noise" to alleviate people's
worries?

I've heard that early Lexus cars had a similar problem.  The cars were so
quiet and well sound-proofed that one couldn't tell by listening whether or
not the engine was running.  This led to a lot of drivers trying to start an
already-running car, and ruining their starters.  In response, Lexus
modified the soundproofing to let a little more noise in, and also modified
the dashboard readouts, making the lights much brighter, so that one could
tell *visually* that the car was running.

I can't confirm that this was really what happened, but it's what my father
told me when I asked about the unusually bright dashboard lights in his
car...

Ari Rapkin


Costs and benefits of war-dialing

"Mich Kabay [NCSA]" <Mich_Kabay@compuserve.com>
Sun, 28 Sep 1997 12:08:31 -0400
At <http://www.zdnet.com:31019/zdnn/content/zdnn/0918/zdnn0010.html>,
Jonathan Littman mentions an interesting aspect of a security scan using a
war dialer:

> Hacker shocker:  Project reveals breaches galore
> Hackers call it "war dialing."
> By Jonathan Littman
> September 18, 1997 2:47 PM PDT ZDNN

> A security expert has used this old hacker's technique to root out
> thousands of modem lines in Northern California that may be leaving
> corporations and individuals vulnerable to attack.

> [He] has been letting his computer do the dialing.  A whole lot of
> dialing: 1.4 million numbers or so; 500 an hour, 12,000 a day.  Roughly
> 14,000 of the 1.4 million numbers [his] program randomly dialed were modem
> lines, a figure that translates to thousands of open doors for would-be
> hackers to wreak havoc.

Readers of RISK wll already have noticed that if 14,000 of 1.4M numbers
dialed were modems, then about 99% of the phone numbers were either
unassigned or were not modem numbers.  So did 1,386,000 people receive calls
from a modem?  Or were the random calls directed solely at known commercial
exchanges?

And it appears from "500 an hour, 12,000 a day" that these calls went out at
all hours.  Which would be preferable, do you think: being bothered by a
modem during working hours or in the middle of the night?

In addition, US Code Title 47 Section 227 (recently discussed in RISKS 19.34
ff), automated calls are forbidden by law in the evening and night-time (the
server for <http://www.law.cornell.edu/uscode/47/227.html> isn't responding
as I write this, so I don't have the exact times).

The fruit of this poisoned tree is not completely rotten, so the article's
interesting findings will be useful in security awareness programs,
especially if the ethical and legal issues are discussed in addition to the
findings.

M. E. Kabay, PhD, CISSP (Kirkland, QC), Director of Education
National Computer Security Association (Carlisle, PA) http://www.ncsa.com


Problems with ACM e-mail forwarding service

<das@nicklas.franken.de>
Wed, 15 Oct 1997 19:48:13 +0100
I have enjoyed reading comp.risks for some time now, but have never
experienced any of the problems recounted there. No invasion of privacy, no
denial of service, no hare-brained computer errors beyond the normal ones
found in commercial software that mostly fails to do reliably what it is
supposed to do. Until now!

The ACM Member Services offers e-mail forwarding to ACM members. Being a
wandering sort, I have used this for a few years in order to have a stable
e-mail address. You can choose the name to use as long as the name is not
already used. My service worked fine until recently, when a fellow member
whom I'll call Smith decided to open a forwarding account under the name
'das'. Now this happens to be my current name in the local account to which
e-mail is forwarded.

It's hard to see how this would screw things up, since acm.org is a
completely different domain from my local one, but I suppose sendmail
screw-ups are like the trees in the forest - uncountable. (I don't actually
know if they're using sendmail. I tried to get the technical details of the
mess, but no one at ACM responded to my request.)

Anyway, test e-mail from Smith to Smith started appearing in my mail. I
forwarded the mail to his real account and he got on the tail of ACM Member
Services. They were somewhat slow to respond, so this went on for a
while. Then I got no more test mail from Smith and assumed everything was
fine. However, my e-mail traffic died off completely, which I took for an
ominous sign, especially when a reply I was expecting did not arrive. In
fact, it did soon arrive, forwarded by Smith. Yes, my e-mail was now being
forwarded to Smith.

I had already alerted ACM to a possible problem and received no answer for a
few days. Now I sent off a somewhat heated complaint. After all, this was no
mere test e-mail; this was my private mail getting sent to a stranger. ACM
finally replied to this and told me the problem was fixed. No apology or
explanation. And, wouldn't you know it, mail to Smith (now private mail)
started getting delivered to me again. At this point, Smith swung solidly
into motion. But by then I had had enough and simply short-circuited the
problem by changing my forwarding address to a local alias. ACM then proudly
informed me that the problem was finally solved, proving this by sending me
a mail that was forwarded to my new alias. I explained to them why this
didn't prove anything, and told them that I and Smith were still lacking a
proper apology and explanation. The apology arrived, but no explanation.

The ACM also managed to reveal presumably confidential information during
our e-mail exchanges. For example, my account number was revealed to Smith
and his to me. This is one of the attributes that give access to the online
services, such as the one that allows you to change the address to which
e-mail is forwarded.

I figure they have earned this article!

David Sedlock


Re: IE4, Netscape, and font anti-aliasing (RISKS-19.41)

"Bryan O'Sullivan" <bos@serpentine.com>
Tue, 21 Oct 1997 13:32:43 -0700 (PDT)
I have been deluged with e-mail since my article about the anti-aliasing of
fonts was published in the last issue of RISKS.  Unfortunately, it was
distributed through an oversight; I had sent mail to the moderator several
days before RISKS "went to press", asking him not to publish the article.

This came about because further investigation on my part had indicated that
the problem seemed to lie with individual fonts not being anti-aliased in
any application, rather than there being a consistent problem with
anti-aliasing in Netscape alone.

It is already well-known that cancelling a Usenet article is no indication
that it will not be seen by a large number of people.  The RISK illustrated
here is, I suppose, that even with a responsive moderator at the helm,
taking the step of asking a human not to publish an article does not
guarantee that it will not be distributed.

  [My apologies for missing the request to cancel the message.
  I had been away for the annual Baltimore security conference and for a
  variety of reasons had gone 16 days without an issue.  Because I had not
  been able to check the RISKS mailbox for two weeks, the backlog included
  many hundreds of would-be contributions (plus a massive number of bounces
  from the previous issue).  I culled out a few that seemed most interesting
  without even beginning to go through the mailbox.  In the future, if you
  wish to withdraw a submission, please CC my personal mailbox, with a
  sensible and relevant subject line, because I am massively deleting
  apparent spams sight unseen (despite ongoing filtering).  PGN]


NCSA CyberRisk 97 Conference

"Mich Kabay [NCSA]" <Mich_Kabay@compuserve.com>
Tue, 21 Oct 1997 13:33:27 -0400
National Computer Security Association invites participation in the
CyberRisk '97 Conference,
The only conference for Internet Liability and Policy Solutions

November 6-7, 1997
Buena Vista Palace Resort & Spa at
Walt Disney World Village, Lake Buena Vista, FL

There are many issues surrounding the Corporate Internet in 1997 including:
acceptable use & policy development, content control, legal liability,
legislative impacts, employee monitoring and management responsibilities.
CyberRisk '97 has been developed to address these issues and offer
practical, real-world solutions to those charged with creating policies and
determining appropriate Internet use for their respective organizations.
The Conference includes an optional Internet Policy Development Workshop.

See <http://www.ncsa.com/events/conferences/cyberrisk97.html>
for full details or call 800-488-4595 and press "2" at the prompt.

M. E. Kabay, PhD, CISSP (Kirkland, QC), Director of Education
National Computer Security Association (Carlisle, PA) http://www.ncsa.com

Please report problems with the web pages to the maintainer

Top