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 21 Issue 87

Saturday 19 January 2002

Contents

Exploding chips: Would you like to be fried with that?
Rob Slade
Hospital tells elderly men they're pregnant
Arthur Goldstein
Automated Debit: "There's nothing we can do to stop it."
Carl Fink
Even unscientific elections get rigged
Jeremy Epstein
The risks of standards and validators
Lindsay Marshall
Buffer overflows and other stupidities
Earl Boebert
Windows update server glitch
Mike Hogsett
An outrageous violation of privacy
Fred Cohen
Risks of Internet Reconfigurable Logic
John Gilliver
Linked DMV databases and biometrics on driver's licenses
Ben Rosengart
Facial recognition technology doesn't work
Nick Brown
Honolulu speed camera risk: mainly human error
Dan Birchall
AOL Buddy-Hole fix has backdoor
Robert Andrews
Reinventing snake oil: compression
Jeremy Epstein
Re: Airplane takes off without pilot
Paul Nelson
Re: Software glitch grounds new Nikon camera
Nickee Sanders
Re: Kaiser Permanente exposes medical record numbers
Geoff Kuenning
Re: ING bank debits wrong sum from accounts
Paul van Keep
REVIEW: "Counter Hack", Ed Skoulis
Rob Slade
Info on RISKS (comp.risks)

Exploding chips: Would you like to be fried with that?

<Rob Slade <rslade@sprint.ca>>
Thu, 17 Jan 2002 08:58:01 -0800

 From NewsScan Daily, 17 January 2002:

> EXPLODING CHIPS COULD FOIL THIEVES
> Researchers at the University of California in San Diego have developed a
> way to blow up silicon chips using an electric signal --

Now, at this point I was willing to dismiss this as the stuff of fiction.
You all know how computers in books and movies always "blow up real good"
when the bad guy plants a virus or something in them.  However:

> an innovation that could be used to fry electronic circuitry in devices
> after they're stolen or fall into the wrong hands. The American spy plane
> that was impounded in China last year is an example where such technology
> would have proven handy in destroying its secret electronics systems.

OK, this make a bit more sense.  Obviously these are chips that are
specifically designed to blow up once they receive a certain signal.

At this point, though, you start to think about what kind of signal that
could be.  And, could it be counterfeited?

> Similarly, if a cell phone were stolen, the owner could alert the wireless
> carrier, which would send a signal to trigger a small explosion in the
> phone's chip, rendering it useless. The techniques uses a small amount of
> the oxidizing chemical gadolinium nitrate applied to a porous silicon
> wafer. (New Scientist 16 Jan 2002)
>   http://www.newscientist.com/news/news.jsp?id=ns99991795

OK, I am definitely certain that, if I need to get a new cell phone from now
on, I am *definitely* not going to carry it in my pants pocket.  The RISKS,
as have been frequently noted here, are obvious.

(If we could get them to use those chips in pacemakers, wouldn't that just
make a killer application, Peter?)

rslade@vcn.bc.ca  rslade@sprint.ca  slade@victoria.tc.ca p1@canada.com
http://victoria.tc.ca/techrev    or    http://sun.soci.niu.edu/~rslade

  [I normally delete all trailer quote.  But this one from another message
  from Rob is rather fascinating:
    A modern US Navy cruiser now requires 26 tons of manuals.
    This is enough to affect the vessel's performance.
      -- `New Scientist' article on the paperless office
  PGN]


Hospital tells elderly men they're pregnant

<arthur.goldstein@att.net>
Fri, 11 Jan 2002 04:19:19 +0000

The Chesterfield and North Derbyshire Royal Hospital admitted on 10 Jan that
it had mistakenly sent computer generated letters to 30 patients, including
six elderly men, telling them they were pregnant.  The system operator was
blamed for choosing the wrong option (instead of informing them that their
operations had been postponed).  [Reuters, 10 Jan 2002, PGN-ed]
  http://news.excite.com/article/id/65168
  |oddlyenough|01-10-2002::11:30|reuters.html  [SPLIT URL]


Automated Debit: "There's nothing we can do to stop it."

<Carl Fink <carl@fink.to>>
Wed, 16 Jan 2002 14:02:08 -0500

A Georgetown, TX man who had arranged for his water bill to be automatically
debited from his bank account alertly noticed that his monthly bill was for
over $21,000.  (If he hadn't noticed, the debit would have happened, causing
him to bounce multiple checks before the error was corrected.)  When he told
the city of the problem, "They said there was absolutely nothing they could
do to stop the automated debit, and it was out of their hands."  Their
solution was to send a city employee with a check for $21,000 to reimburse
their customer!
  http://www.austin360.com/statesman/editions/tuesday/metro_state_1.html

Risks?  Lack of sanity checking on a new billing system springs to
mind.  Lack of any way to correct errors is also quite prominent.

Carl Fink, Manager, Dueling Modems Computer Forum  http://dm.net/ carlf@dm.net


Even unscientific elections get rigged

<"Jeremy Epstein" <jepstein@webmethods.com>>
Wed, 9 Jan 2002 16:28:26 -0500

ZDNet is doing a poll on whether J2EE or .NET is more important for Web
services.  Although it's a totally unscientific poll, they've set things up
to try to detect (and stop) ballot stuffing.  It seems that Microsoft hasn't
understood the concept, and employees are trying to vote repeatedly,
including automated voting.
  http://news.zdnet.co.uk/story/0,,t269-s2102244,00.html

The risk of believing unscientific polls is nothing new, but the combination
of electronic polls that can be stuffed with the herd mentality that may
influence buying greatly increases the risks.

  [*The Register* noted that 21.5% of the respondents said they would
  use .Net, 46% Java -- until a surge of votes came in from microsoft.com,
  some of which were apparently stimulated by internal MS e-mail saying
  "PLEASE STOP AND VOTE FOR .NET!".  PGN]


The risks of standards and validators

<"Lindsay Marshall" <Lindsay.Marshall@newcastle.ac.uk>>
Fri, 11 Jan 2002 13:16:36 -0000

This week I ran a page of the RISKS Web site through the W3 html validator,
as I do on a regular basis -- it keeps me clean and legal.  It complained
that I didn't have a charset specification, so I added one as it suggested.
This appears to cause some netscape 4.7 browsers some problems -- I had
complaints that the text was vanishingly small, and also that it was vastly
increased in size.  Presumably a typeface selection that is hard-wired
somewhere, and that nobody is told about.  Anyway, I've taken out the
charset setting for the moment.

http://catless.ncl.ac.uk/Lindsay

  [Lindsay runs our UK redistribution and the excellent RISKS Web site --
  for both of which I am most grateful.  I'm delighted to take the
  opportunity to thank him once again!  PGN]


Buffer overflows and other stupidities

<Earl Boebert <boebert@swcp.com>>
Mon, 14 Jan 2002 10:07:55 -0700

  "I used to be disgusted, now I try to be amused."  -- Elvis Costello
  "What a stupid robot." -- Marvin the Paranoid Android

In my view, attempts to close the buffer overflow vulnerability through
software or compiler tricks are doomed to one degree of failure or another
because you're trying to program around a stupid processor design.  Certain
contemporary processors actually host a Pantheon of stupidities, consisting
of a Greater Stupidity and two handmaiden Lesser Stupidities.

Greater Stupidity: Read access implying execute access. Any piece of data
that the processor can be tricked into loading into the command register
immediately becomes code. This is a stupidity of such breadth and depth that
it comes with an event horizon.

Lesser Stupidity I: Segmented addressing that isn't. Let's say you have an
addressing scheme consisting of segment number plus offset. This raises the
question of what to do when, in executing code, block moves, etc., the
offset gets counted up to maximum length plus one. Smart answer: take a
fault. Dumb answer: set offset to zero and count up one in segment number.

Lesser Stupidity II: Brain-dead stack design. If you enumerate the design
space of dynamic storage management, you may realize that one actually has
to *work* to produce a stack design so dumb that overflow attacks are
possible. Here are four classes of designs that are immune to the
vulnerability:

1. Descriptor stacks.  The only thing that goes in the stack are addresses,
preferably with a bounds value attached. Overflow a buffer and at worst you
clobber the heap. Penalty: one level of indirection, which (The Horror! The
Horror!) may cause your dancing pigs to dance slower than the other
guy's. Possibility: can be fitted transparently to existing processor
designs, assuming anybody cared.

2. Stack per protection domain. This assumes you can find the perimeters of
your protection domains. Also slows down dancing pig displays because of
copying parameters from stack to stack.

3. Separate control and data stacks. CALL/RETURN works the control stack,
PUSH/POP works the data stack. Doh.

4. Error-checking stacks. A whole raft of options, including "shadow stacks"
with checksums, return addresses protected with trap bits, etc. etc.

So, if it's all so straightforward and well known, why hasn't some vendor or
other fixed it?  Answer: the dancing pigs have won.

  [Ah, yes.  Earl is tacitly recalling the good old days of Multics
  (beginning in 1965) and its progenies (SRI's object-oriented Provably
  Secure Operating System design 1973--1980, and the Honeywell/Secure
  Computing Corporation type-enforced systems), all of which took care of
  this problem and so many others so long ago.  But with today's badly
  designed bloatware, the dancing pigs are increasingly becoming 700-pound
  porkers that can barely move around the pigsty without massive memory
  and processing power, and whose pigpen could not even contain them if
  they were in reality Trojan pigs.  PGN]


Windows update server glitch

<Mike Hogsett <hogsett@csl.sri.com>>
Tue, 15 Jan 2002 14:48:14 -0800

A glitch in Microsoft's server software has left some users unable to
download important security patches and other fixes for Windows software
since last Thursday.

  http://www.cnn.com/2002/TECH/internet/01/15/microsoft.security.server.ap/index.html

  http://www.cnn.com/2002/TECH/internet/01/15/
  microsoft.security.server.ap/index.html   [SPLIT]


An outrageous violation of privacy

<Fred Cohen <fc@all.net>>
Sun, 13 Jan 2002 10:27:20 -0800 (PST)

I just saw a piece on MSNBC where they prominently featured the face of a
man who helped someone out of the WTC on 11 Sep 2001 -- and just because
they don't know who the man is, they have created a composite picture of him
and posted him as if he were a wanted man on the national news.

Now I understand their desire to make human interest stories go, but I think
it is outrageous to take the image of a person and smear it all over
national TV, creating a manhunt for someone, when all the person did was to
help someone else out in a public place.

If I were this man, I would sue them for as much as I could get and do all I
could to try to recover what semblance of privacy I might barely still have
left after being exposed on national TV without my permission.

Is this all we have left of our privacy?

Fred Cohen http://all.net/ Fred Cohen & Associates tel/fax:925-454-0171
Sandia National Laboratories 1-925-294-2087  University of New Haven


Risks of Internet Reconfigurable Logic

<john.gilliver@baesystems.com>
Tue, 08 Jan 2002 16:40:35 +0000

  ... "For example, IRL (Internet Reconfigurable Logic) means that a new
  design can be sent to an FPGA in any system based on its IP address."
  (From Robert Green, Strategic Solutions Marketing with Xilinx Ltd., in
  "Electronic Product Design" December 2001.  Xilinx is a big manufacturer
  of FPGAs.)

For those unfamiliar with the term, FPGA stands for field-programmable logic
array: many modern designs are built using these devices, which replace tens
or hundreds of thousands of gates of hard-wired logic.

The RISKs involved are left as an exercise to the readers ...

J. P. Gilliver, BAE SYSTEMS Advanced Technology Centre,
West Hanningfield Road, GREAT BADDOW, Essex, CM2 8HN, UK  +44 1245 242133


Linked DMV databases and biometrics on driver's licenses

<Ben Rosengart <ben+risks@narcissus.net>>
Wed, 9 Jan 2002 17:38:14 -0500

*Time Magazine* is reporting that the federal Department of Transportation,
by instruction of the Congress, is working to link together the states'
driver databases, and also to introduce biometric security on drivers'
licenses.

http://www.time.com/time/nation/article/0,8599,191857,00.html

RISKS include false arrest due to database screwups, abuse for personal
reasons by government personnel, abuse by the government itself, all the
RISKS known to be associated with biometrics, disclosure of the databases to
the public, and probably much, much more.


Facial recognition technology doesn't work

<Nick Brown <Nick.BROWN@coe.int>>
Wed, 9 Jan 2002 11:38:39 +0100

An article by the ACLU at
  http://www.aclu.org/issues/privacy/drawing_blank.pdf reveals that a
highly-publicised facial recognition system has been quietly dropped by law
enforcement officials in Tampa, Florida, following a large number of false
positives (including males identified as females, and vice versa) and a
total of zero matches against known criminals, leading to zero arrests.

Aside from the already-discussed civil liberties RISKs of such systems, it
seems we need to add the possibility that the taxpayers may not be getting
value for money, with or without their knowledge (the withdrawal of this
kind of thing tends to be done with rather less media coverage than its
introduction).  One wonders if this will have any effect on plans to
introduce such systems into airports to "detect" terrorists.

Nick Brown, Strasbourg, France


Honolulu speed camera risk: mainly human error

<Dan Birchall <djb@nospam.danbirchall.com>>
Wed, 9 Jan 2002 22:52:58 -1000

After much debate, and general wailing and gnashing of teeth from those who
like to drive fast, the powers that be here in Honolulu have a private
contractor operating cameras to photograph vehicles which speed or run red
lights.  After the license number, time, and location of the violation are
verified, a citation is mailed.

In their first day of operation, the cameras caught 927 speeders.
  http://starbulletin.com/2002/01/03/news/index1.html

However, more than 80% were unenforceable due to human errors in operation
of the cameras - poor aim, inaccurate location recording, etc.
  http://starbulletin.com/2002/01/08/news/index4.html

On the bright side, people do seem to be speeding less since the cameras
started working.

http://danbirchall.com/


AOL Buddy-Hole fix has backdoor

<"Robert Andrews @ PrivacyExposed.com" <Robert@PrivacyExposed.com>>
Wed, 9 Jan 2002 12:19:10 -0400

"A member of w00w00, the security enthusiasts who first reported the AOL
Instant Messenger (AIM) games request vulnerability, has alerted users that
a fix the group recommends has its own backdoor.  Apparently, the AIM Filter
by Robbie Saunders which w00w00 had recommended is infected, group member
Jordan Ritter disclosed on the Bugtraq mailing list late Tuesday. "At the
time, Robbie Saunders' AIM Filter seemed like a nice temporary solution.
Unfortunately, it instead produces cash-paid click-throughs over time
intervals and contains backdoor code combined with basic obfuscation to
divulge system information and launch several Web browsers to porn sites,"
Ritter wrote."  [...]  Thomas C Greene, *The Register*
http://www.theregister.co.uk/content/4/23596.html


Reinventing snake oil: compression

<"Jeremy Epstein" <jepstein@webmethods.com>>
Wed, 9 Jan 2002 16:13:31 -0500

Snake oil is on the rise.  Latest to join the fray is Zeosync
(www.zeosync.com), which announced on 7 Jan 2002 that they have new
algorithms that can provide 100:1 lossless data compression over
"practically random" data.  (What they mean by "practically" isn't defined.)
Lots of criticism and proofs that it's impossible in Slashdot
  http://slashdot.org/article.pl?sid=02/01/08/137246&mode=thread
and elsewhere.  So far the algorithms haven't been given, except to provide
the single longest stream of buzzwords I've seen in a long time.  The one
part that says it might not be 100% snake oil is that they have a Fields'
Prize winner as one of the participants.

The risk here is that they've added enough buzzwords to the announcement
that some people might actually believe it.  The media doesn't seem very
skeptical, which they should be.  Reuters quoted David Hill, an analyst with
Aberdeen Group as saying "Either this research is the next 'Cold Fusion'
scam that dies away or it's the foundation for a Nobel Prize. I don't have
an answer to which one it is yet."  Others have been much more willing to
figure out which way it's going.  Remember the 1999 story about the
16-year-old Irish girl whose new form of cryptography would revolutionize
the world?


Re: Airplane takes off without pilot (Klein, RISKS-21.84)

<pnelson@sauer-danfoss.com>
Mon, 7 Jan 2002 15:20:53 -0600

There are many aircraft which have no starters (or electrical system, for
that matter)- commonly antique or classic small, one- or two- place planes
like the 1947 Aeronca Champ that was the subject of this item. There are
well-known safety precautions which go along with starting them- one of the
oldest is that there should be someone in the cockpit with feet on the
brakes, operating the magneto switches and throttle while a second person
"props" the plane to start it. (The classic shouts "CLEAR!", "CONTACT!",
"SWITCH OFF!", "BRAKES", "THROTTLE BACK AND CRACKED!" come to mind.)

If a plane like this is to be started by one person, the accepted
precaution is to tie the tailwheel to a stationary object, turn the fuel
OFF so that only the small amount in the carburetor bowl is available, and
then make CERTAIN that the throttle is only cracked open a small amount.
I've started my 1946 Cessna 140 in this manner many times when the battery
happened to be run down.

All that being said, incidents like this still happen when people try to
take shortcuts. It shouldn't have happened!

Paul Nelson, Senior Engineer, Sauer-Danfoss Company, Ames, IA  515-239-6614


Re: Software glitch grounds new Nikon camera (Gillett, RISKS-21.85)

<Nickee Sanders <njs@ihug.co.nz>>
Wed, 9 Jan 2002 12:10:32 +1300

Our first digicam was also a Kodak.  When the battery voltage was low enough
(and it happened suddenly), the camera would simply stop responding to *any*
user actions whatsoever.  It didn't even do a power down.  The only way to
clear this condition was to take the batteries out for a number of hours;
after this, on insertion of fresh batteries, the camera would power down and
then could be powered up again.

The first time this happened it was pretty scary.  One minute we were
snapping away; the next minute the camera was frozen, with the lens fully
extended (and thus the lens cap wouldn't stay on it).  The local service
reps knew nothing of this error condition and could only offer to send it to
Australia (from New Zealand) for servicing, which would take several weeks.
We figured out by trial and error how to solve it ourselves.

Nickee Sanders, Auckland, New Zealand


Re: Kaiser Permanente exposes medical record numbers (Debert, R-21.86)

<Geoff Kuenning <geoff@cs.hmc.edu>>
Mon, 14 Jan 2002 13:09:28 -0800

J. Debert writes about an insecure Web page at http://www.kponline.org.

It happens that my best friend works for Kaiser Permanente's IT department,
so I forwarded the message to her.  As a result of discussions and
exploration, I think that the alleged risk does not in fact exist.

The claim was that medical-record numbers were being exposed during the
signon process.  However, in viewing the source of the referenced Web page,
it appears that the "sign on" button makes an https (SSL) connection.  Thus,
although the "padlock" icon in the browser is unlocked, anything sent from
that page is in fact sent using SSL.

I have recommended that Kaiser change their main page so that it forwards
the browser to an SSL equivalent, solely so that the padlock icon will
appear locked.

I think that the true RISK is not in Kaiser's Web page, but rather in the
browser.  The "padlock" icon reflects not whether the page SENDS information
securely, but rather the fact that the page was FETCHED securely.  This
disconnect between what is shown and what is expected has been raised
recently by Jeff Mogul in the converse direction: a page that had the
padlock proceeded to send information insecurely.

The first problem (apparently insecure page is actually secure) can be
patched around with the forwarding kludge I mentioned above.  The second can
be handled by the user to some extent (certain browser settings can warn you
when you transition from a secure page to an insecure one).  However, the
true problem is in browser design.  The "padlock" icon should be associated
with a LINK, not a page.  Regardless of how it was fetched, if a page
contains both secure and insecure links, the lock should be shown as
unlocked and should lock only when you mouse over a secure link.  Only if
all outgoing links from a page are secure should the padlock be permanently
displayed in its locked form.

    Geoff Kuenning   geoff@cs.hmc.edu   http://www.cs.hmc.edu/~geoff/



Re: ING bank debits wrong sum from accounts

<Paul van Keep <paul@sumatra.nl>>
Wed, 9 Jan 2002 11:04:45 +0100

Several people have pointed out that I was wrong in my statement about
disproving a 10000 euro cash withdrawal would be tough. Banks have a sane
upper limit on the amount of cash you can withdraw from an ATM, even at your
own branch. That limit is somewhere below 2000 euro. A 10000 euro ATM
transaction is therefore totally impossible.

Paul van Keep


REVIEW: "Counter Hack", Ed Skoulis

<Rob Slade <rslade@sprint.ca>>
Mon, 14 Jan 2002 07:34:47 -0800

BKCNTRHK.RVW   20011023

"Counter Hack", Ed Skoulis, 2002, 0-13-033273-9, U$49.99/C$75.00
%A   Ed Skoulis
%C   One Lake St., Upper Saddle River, NJ   07458
%D   2002
%G   0-13-033273-9
%I   Prentice Hall
%O   U$49.99/C$75.00 800-576-3800 416-293-3621
%P   564 p.
%T   "Counter Hack"

Chapter one, as in many texts, is an introduction to the book, but is
unusually important in this case.  First, Skoulis lays out the philosophy
behind the work.  While the text of the book does concentrate on attacks,
the author points out that invaders already have other sources of
information.  Further, Skoulis proposes that a detailed, complete, and
integrated examination of representative samples of classes of attacks will
provide an outline of defensive measures that can protect against a wide
variety of assaults.

A second point in this introduction is a brief examination of the character
of attackers.  Skoulis does point out that those who attempt to penetrate
computer and communications security do so from a diversity of motivations
and skill levels.  However, he does tend to overstress the participation of
"professional hackers," proposing that industrial espionage, terrorism, and
organized computer crime activities are common.  Certainly such campaigns
may become common, making the need for pre-planning even more important, but
the vast majority of endeavors we are seeing at present are amateur efforts.

Finally, the introduction recommends the establishment of a computer
security test laboratory, which is an excellent idea for any large
corporation, but probably is not within the financial, personnel, or
educational reach of even medium sized businesses.

Chapter two provides a background in TCP/IP for the purposes of discussing
networking offence and defence.  There are frequent forward references to
later sections of the book that deal with network attacks.  The material
could, however, have been condensed somewhat to emphasize those aspects of
the protocols that are closely related to security.  UNIX and Windows (NT
and 2000) are similarly covered in chapters three and four, and, again, the
text could be tightened up by focusing on safety factors.

Chapter five points out the ways in which people can obtain data in order to
direct and mount an attack.  While the content is informative, and there are
a  few suggestions  for restricting  the release  of such  intelligence, the
defensive value of  the text is limited.  The  information gathering process
continues  in chapter  six with  war dialling  and port  scanning.  Defences
against application  and operating system  attacks are covered a  bit better
than  in most  "hacking" books  (there are  descriptions of  buffer overflow
detection  tools),  but the  protective  value  of  chapter seven  is  still
questionable.  Chapter eight  examines network sniffing, scanning, spoofing,
and hijacking.  Denial of service  is covered well in chapter nine.  Various
examples of malware are described in chapter ten.  Chapter eleven deals with
the means used to hide an attack.

A number of scenarios are created in chapter twelve.  Chapter thirteen
describes some resources for keeping up with the latest computer
vulnerabilities.

Recently there has been a flood of books to the security marketplace, all
based on the premise that if you know how to attack a system, you will know
how to defend it.  Skoulis has done a better job than most, but the thesis
is still unproven.  Yes, knowledge of the details of an attack does help you
fine tune your defence.  Yes, providing specifics of an example of a class
of attacks does help you consider a protective mechanism that might work
against a whole class.  Yes, Skoulis does recommend safeguards for most of
the attacks listed.  But taking a crowbar to a padlock still doesn't teach
you locksmith skills.

copyright Robert M. Slade, 2001   BKCNTRHK.RVW   20011023
rslade@vcn.bc.ca  rslade@sprint.ca  slade@victoria.tc.ca p1@canada.com
http://victoria.tc.ca/techrev    or    http://sun.soci.niu.edu/~rslade

Please report problems with the web pages to the maintainer

Top