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 62

Saturday 25 August 2001

Contents

Oklahoma whistleblower asked to accept felony conviction
Deborah Weisman
Follow-up on Oklahoma whistleblower
PGN
Wireless security vulnerabilities
PGN
AirSnort!
PGN
Kaiser Permanente
identity withheld by request
Air Force officer mails confidential information to all cadets
Jim Griffith
Re: Avoiding prosecution of the DMCA
David Petrou
Fred Cohen
Re: Why I don't publish my HDCP results
Bill Weitze
David Gillett
Re: rot13
Mike Perry
Hack the vote? Not in Broward County!
James Paul
Re: Runway incursions
Bill Hopkins
Code Red 9? Code Crimson
Alistair McDonald
AT&T - the computer MUST be right!
Sharon Mech
Re: DejaGoogle rides again
Geoffrey Leeming
Re: Risks of automated junk/spam filters
AlphaLau
Yet another MS Hotmail risk
Kimmo
REVIEW: "SSL and TLS", Eric Rescorla
Rob Slade
Dependable Systems and Networks DSN-2002 Call for Contributions
Anup Ghosh
Info on RISKS (comp.risks)

Oklahoma whistleblower asked to accept felony conviction

<Deborah Weisman <dvorah@agri.huji.ac.il>>
Wed, 22 Aug 2001 10:40:06 +0300

A Federal prosecutor has asked Brian West, a 24-year old sales and support
employee of an Oklahoma ISP "to accept a felony conviction and 5 years
probation" for notifying the editor-in-chief of his local newspaper *Poteau
Daily News* that they had failed to set up password security for their Web
site: no authentication, anyone could edit the site using Microsoft
FrontPage.  Following their phone conversation, the EIC gave a tape of the
conversation to the Poteau Police Department, who invoked the FBI.
  [http://www.macintouch.com/newsrecent.shtml; PGN-ed]

Computer Center Faculty of Agriculture Hebrew University of Jerusalem
P.O.B. 12 Rehovot 76100 ISRAEL  972-8-9489232  dvorah@agri.huji.ac.il

  [Also noted by Ron LaPedis at
     http://www.linuxfreak.org/post.php/08/17/2001/134.html. PGN]


Follow-up on Oklahoma whistleblower

<"Peter G. Neumann" <neumann@csl.sri.com>>
Sat, 25 Aug 2001 10:12:13 PDT

Sheldon Sperling <Sheldon.Sperling@usdoj.gov>, the U.S. Attorney in the
Brian K. West case, has responded to various e-mail protests on his handling
of the case.  He claims that West was not arrested and has not been charged.
However, an investigation is pending, to determine whether West
"intentionally accessed a computer without authorization or exceeded
authorized access (to access a computer with authorization and to use such
access to obtain or alter information in the computer that the accesser is
not entitled so to obtain or alter), (2) whether the employee thereby
obtained information from a protected computer (a computer which is used in
interstate or foreign commerce or communication), and (3) whether the
conduct involved an interstate communication.  18 USC 1030."  [The full
statement from Sperling is included in a message from Declan McCullagh,
which is accessible at http://www.politechbot.com/ .]

I have noted in this space before that when there is no security in place,
the alleged culprit cannot have exceeded authority when no authority is
implied.  As long-time RISKS readers will recall, this issue came up
relating to the trial of Robert Tappan Morris: in 1988, the Internet worm
never exceeded authority, because no authority was required to use the
sendmail debug option, to use the .rhosts mechanism, to execute the finger
daemon, or to read an unprotected encrypted password file.  I wonder how
if prosecutors will ever figure this out!

As long as we attempt to shoot the messenger and hide lame security behind
overly broad laws, weak security will prevail, and whistleblowers will be
much rarer than glassblowers.  (For example, DMCA is among other things an
attempt to outlaw whistleblowers.)


Wireless security vulnerabilities

<"Peter G. Neumann" <neumann@csl.sri.com>>
Sun, 19 Aug 2001 13:16:18 PDT

Sitting in the Morristown (N.J.) Memorial Hospital, AT&T Labs' Avi Rubin (a
note from Avi on WEP insecurity is in RISKS-21.57) noticed that his laptop
wireless connection card was blinking, and then discovered that the
hospital's wireless network was open to his laptop, using 802.11b (Wi-Fi)
and automatically granting him access.  [Source: As Wireless Networks Grow,
So Do Security Fears, by John Schwartz Sunday Business Section of *The New
York Times*, page 10, 19 Aug 2001 (National edition), PGN-ed; full article at
  http://www.nytimes.com/2001/08/19/technology/19WIRE.html]
    [Another case of *not* having to exceed authority because there was
    no security involved!  Sloppy hospital?  Insecurity by obscurity?  PGN]


AirSnort!

<"Peter G. Neumann" <neumann@csl.sri.com>>
Fri, 24 Aug 2001 11:52:33 -0700

AirSnort, WEPCrack, and other programs available on the Internet make it
easy to sniff sensitive data such as passwords that fly around 802.11b
wireless Internet networks.  A competing standard, Bluetooth, is not
susceptible, although Bluetooth is considered "more vulnerable to spies than
hard-wired networks."  [Source: AP item, 24 Aug 2001, courtesy of Ken Nitz;
PGN-ed]

The vulnerabilities have been noted here before, but now maybe there
will be some incentives to do something about it?  On the other hand,
probably not, if our historical RISKS warnings are not observed, as usual.


Kaiser Permanente

<identity withheld by request>
Tue, 21 Aug 2001 19:23:53 -0700

There's a self-service section on the Kaiser Permanente (an HMO) Web site at
http://www.kaiserpermanente.org/ that allows you to notify them of a change
of address.  In bold letters next to the submit button, it claims "Your
information is secure!".  Sounds good.  Checking View Source showed the form
was being submitted over SSL.  Ok, let's submit the information.  A few
minutes later an e-mail arrives.  No encryption.  Ouch -- it contains a
verbatim copy of the personal information I typed into the form.  So much
for "Your information is secure!".

Why bother breaking SSL flows, when you can just watch the e-mail?


Air Force officer mails confidential information to all cadets

<Jim Griffith <griffith@olagrande.net>>
Sat, 25 Aug 2001 14:48:44 -0500

AP reports that an Air Force Academy officer accidentally sent confidential
information about some 40 cadets to all 4400 cadets at the school.  The mail
in question contained details of past and pending disciplinary issues,
including the identity of confidential informants in some cases.  The
information in question was reportedly protected by federal law, and
officials subsequently ordered cadets to delete the letters.

http://www0.mercurycenter.com/breaking/docs/044576.htm


Re: Avoiding prosecution of the DMCA (Ferguson, RISKS-21.60)

<David Petrou <dpetrou@cs.cmu.edu>>
Sun, 19 Aug 2001 20:56:30 -0400

Just staying out of the U.S. won't necessarily do the trick.  The DoJ can
obtain an arrest warrant based upon a criminal violation of the DMCA and
seek extradition from a number of countries.  If US law is violated and the
country where the person is has an extradition agreement with the United
States, the foreign government will cooperate in arresting the person and
having that person delivered to the United States for prosecution.


Re: Avoiding prosecution of the DMCA (Ferguson, RISKS-21.60)

<Fred Cohen <fc@all.net>>
Fri, 17 Aug 2001 15:47:51 -0700 (PDT)

The DMCA has also had effects on my forensic analysis products.  Because the
current copyright law makes anything that is put into tangible form
copyright unless made otherwise by the author (or by law), things like
criminal records are copyright.

This means that if the criminal tries to protect their material - for
example by hiding it using steganography, encrypting it, or by putting
it on a computer with a password to prevent unauthorized access - then
that work is protected by the DMCA (after all, the password on Windows
systems is effective protection unless you try to circumvent it).

Because the primary purpose of most of my forensic analysis tools is to
reveal things that are protected from revelation, and because the DMCA
makes it illegal to distribute such a device, I have been forced (based
on the recent arrests and other threats against authors of such things)
to withdraw my forensic products from the market.

I should note that companies like Access Data who sell products that are
explicitly designed for undoing encryption, etc.  are almost certainly in
violation of the DMCA.  While the FBI might not arrest them now because they
sell to the FBI (and other in law enforcement - as did I), this does not
mean that the FBI cannot arrest them at any time and charge them with a
felony.  Indeed, sale to law enforcement is not legal, even though law
enforcement can, on its own, build and use such tools.

The effects on research and education are even more interesting.  For
example, I am having a discussion with my university now about canceling
courses on forensics and cryptanalysis because in these courses we teach
people how to get around protection of this sort and may provide the
capabilities to do so in so teaching.  The DMCA has, I believe, made this
illegal - and if you are teaching such a course next semester, you might
think about the issues as well.  On the research side, I don't work on
research I cannot publish, so I am canceling the aspects of my research
that go into these areas.

Fred Cohen		Fred Cohen & Associates.........tel/fax:925-454-0171
fc@all.net		The University of New Haven.....http://www.unhca.com/
http://all.net/		Sandia National Laboratories....tel:925-294-2087


Re: Why I don't publish my HDCP results (Ferguson, RISKS-21.61)

<"Bill Weitze" <bweitze@california.com>>
Fri, 17 Aug 2001 21:36:04 -0700

Hmm, a blind person could sue the publisher under the Americans with
Disabilities Act.

> Why did the movie industry campaign for the DMCA if it doesn't work? The
> movie and record industry have a history of claiming that new technologies
> will bankrupt them.

They complain about paper books, too.  In the September 18, 2000 issue of U.S.
News and World Report, p. 55, an article titled "The empire strikes back"
states the following:

  A typical book, for example--the old-fashioned kind--finds its way to five
  or six readers beyond the original purchaser, according to Laurence
  Kirshbaum, CEO of Time Warner's trade-publishing arm.  "One of the
  attractions of electronic publishing," he says, is the ability to "cut down
  on this pass-along."

I wrote to U.S. News as follows:

  This "loaning", as its practitioners call it, is indeed most subversive.
  There are even institutions, called "libraries", which carry on this sort
  of thing in a wholesale fashion.  This was started by a very dangerous
  individual named Franklin; maybe Mr. Kirshbaum should sue him.

Bill Weitze, San Jose, CA


Re: Why I don't publish my HDCP results (Ferguson, RISKS-21.61)

<David Gillett <dgillett@deepforest.org>>
Fri, 17 Aug 2001 16:38:04 -0700

To my mind, one of the more dangerous aspects of DMCA is the deliberate
conflation and confusion of "copy protection" (use restriction mechanisms)
with "copyright protection".  Experience has already shown that the former
are not an acceptable substitute for the latter, a lesson which DMCA
attempts to unlearn by fiat.


Re: rot13 (RISKS-21.58 and .59)

<"Mike Perry" <PERRYM@uk.ibm.com>>
Tue, 21 Aug 2001 18:55:08 +0100

If companies are using rot13 to "encrypt" copyrighted information, doesn't
that make every unix user in the USA a criminal under the DMCA?  It would be
interesting to see what would happen to "the system" if a few million people
went to the police and confessed...


Hack the Vote? Not in Broward County!

<james.paul@mail.house.gov>
Fri, 17 Aug 2001 23:03:31 -0500 (CDT)

In RISKS-21.61, Adam Shostack noted that Broward County was apparently going
to let students have a crack at their new touch-screen voting systems.  Bob
Cantrell, director of intergovernmental affairs for the Broward Supervisor
of Elections, claims that this will not happen.  [Source: William Welsh, 17
Aug 2001 *Washington Technology*, PGN-ed from
  http://www.washingtontechnology.com/news/1_1/daily_news/17017-1.html]


Re: Runway incursions

<"Bill Hopkins" <whopkins@wmi.com>>
Fri, 17 Aug 2001 19:35:42 -0400

The runway-incursion system that's behind schedule (RISKS-21.60) is the
Airport Movement Area Safety System (AMASS).  It uses data from the Airport
Surface Detection Equipment (ASDE-3), a primary radar.  "Primary" means it
relies on reflections, not transponders, for detection and ranging.

It seems to me that any system that relies only on position tracking is
going to have a tough time reliably detecting incursions without racking up
lots of false alarms.  The distance from the hold-short line to disaster is
so small and the time to react so limited that the alarms have to be set to
go off on very small changes.  Variations in RF propagation, changing
reflections from other moving aircraft (or service trucks), and system
instabilities almost guarantee that they will when nothing is wrong.  The
technical folks may be able to tune each system to a level that ATC finds
acceptable, but it will be slow, labor-intensive, frequent, site-specific,
and expensive.  Results will vary from facility to facility.

Much better systems are technologically feasible.  Flight Management Systems
know when the aircraft is stopped, when its brakes are off, when the engines
are spooling up.  A prototype FAA system controls red Runway Status Lights
(RWSL) for visual back-up to "hold short" instructions, based on whom the
controller has cleared to use the runway.  The next generation aircraft
radios have provision for addressable data link.  Moving map displays are
increasing common.  Limited vocabulary speech understanding is increasingly
reliable.

Mix these together with some intelligent design for the controller's
display, and the runway monitor can raise a fuss when the pilot fails to
acknowledge a "hold short", or the brakes come off too early, not when the
radar jitters.  Most operational errors by ATC and pilots will be prevented
by putting redundant information where it is useful instead of relying on
memory; others will be caught and corrected early.  Life will be good.
Stocks will rise.  Politics will be civil.  PGN's puns will all be funny.
To all of us.

The risk: believing it might actually happen in our lifetime?

    Bill Hopkins (whopkins@wmi.com, no longer in the ATC biz)


Code Red 9? Code Crimson

<Alistair McDonald <alistair@bacchusconsultancy.com>>
Fri, 24 Aug 2001 16:06:13 +0100

Two weeks into the Code Red exploit, when variant II or III or whatever you
want to call it was particularly active, incidents.org noticed that another
MS security flaw was being exploited. Their report is here
http://www.incidents.org/diary/august2001.php#132. They give no data as to
how many compromised systems are out there, possibly the reported probes are
all an attempt to "jump start" the worm.

The vulnerability is described at
http://www.microsoft.com/technet/security/bulletin/ms01-023.asp. Again,
there has been a patch available for some time (since May, apparently), yet
I'm sure that some systems will be unpatched. My Win2K SP2 machines did not
need the patch, so I guess it's installed with SP2.

When will the world wake up and stop buying software from a software company
that obviously can't write software well?

[Actually, the buying decision is probably done by people who know little
about software, IMO].

Alistair McDonald, Bacchus Consultancy Ltd  http://www.bacchusconsultancy.com


AT&T - the computer MUST be right!

<"Sharon Mech" <sharon@cmhcsys.com>>
Fri, 17 Aug 2001 17:26:03 -0400 (EDT)

Our long distance service is plain, vanilla AT&T service. Long-distance
charges appear on our local Ameritech phone bill. This past month, we got
a bill showing charges for the AT&T One Rate plan, for which we had not
signed up. (We also have an anti-slamming policy signed & on file.) So I
called Ameritech. After negotiating their automated attendant hell, I was
told that there was nothing they could do - I needed to call AT&T. At AT&T, more
automated attendant hell. When I get the rep on the line, I give her my
phone number and name, and explain the problem. She tells me that she can't
help me, because our phone number has someone else's name on it, and neither
I nor my husband is that person (whose name she will not reveal - I guess
privacy does matter!) and she can't give me to a supervisor, thank you for
calling AT&T! Just a note: We've lived at our house for 7 years, and always
had the same area code and phone number. Apparently the AT&T record had been
changed in February of this year, and our phone number was now associated
with a different name and address. If there was a notation of who authorized
the change, she sure didn't tell me - after all, it wasn't my phone line....

Back to Ameritech. Their rep confirmed that our line was indeed our line, in
my name, at our address. I was fortunate - this rep had initiative. Once I
explained the situation (took a couple of repeats) he put me on hold &
called AT&T to set up a conference call. Things almost fell apart at this
point, because Ameritech reps have a pretty strict time limit on their
calls. We got an AT&T rep on the phone at just about the limit. He went on
to explain to the AT&T rep that my line was really my line. She wasn't
buying it - after all, her computer MUST be right, but finally grudgingly
agreed to amend her record, noting his ID, info, etc. as
justification. Finally we could get to the point of removing the unwanted
calling plan. Mission accomplished. One last detail - the calling plan cost
a certain amount, but also involved a credit. Because the plan changes
tariffs & long distance rates, our long- distance usage (minimal) had been
billed at the wrong rate, and neither of the reps could tell me what we
actually owed.

Sharon Mech <sharon@cmhc.com>


Re: DejaGoogle rides again (Weingart, RISKS-21.61)

<"Leeming, Geoffrey" <gleeming@lehman.com>>
Mon, 20 Aug 2001 08:59:45 +0100

What risks?  If you read a post in Deja/Google it gives you a nice link to
the rest of the thread.  Full marks to Google for only giving one link to
the thread as a whole, not one to each of the entries.  If it had been the
wrong thread, getting one link to each entry would have meant that the next
search result would have been pushed way down the list.

Geoffrey Leeming, Technical Security Manager
Lehman Brothers International Ltd.  +44 (0) 20 7260 1338

  [Also noted by several others.  PGN]


Re: Risks of automated junk/spam filters (Loftis, RISKS-21.60)

<AlphaLau <avlxyz@yahoo.com>>
Wed, 22 Aug 2001 09:14:01 +0100 (BST)

Unfortunately, this happens with Yahoo Mail as well.  Their "Bulk Mail"
feature is similar, and you used to be able to specify if an email was
indeed not spam. Of course what they actually did with it...

Y!Mail also has a nifty "Block email from this Address" feature that will
send email with those addresses into a blackhole.

I have suggested to Yahoo to keep a log of blackholed emails, just the date,
from, to & subject fields should be enough. All I got in reply was, that is
how the blocking works. Use Y!Mail Filter to manually handle it.

So in effect, users are saddled with 2 spam "features" that are not really
useful. I have disabled both.

Still, Y!Mail is one-up on Hotmail with it's block-mail feature! :)

Alpha


Yet another MS Hotmail risk

<Kimmo <kimmo.pyykko@sonera.com>>
Mon, 20 Aug 2001 17:44:25 +0300

One addition on Michael Loftis' article about MS's Hotmail service
(http://catless.ncl.ac.uk/Risks/21.60.html#subj11):

I also have a Hotmail account to handle the private mail and I noticed
today an interesting behaviour concerning the Junk Mail-folder:

Now, logging in this morning (Aug 20) I noticed a warning mail from
Hotmail Staff (Aug 18) that my account size is too large. Opening the
mail was impossible, because all I got was a warning that I was 5120K
over my quota. Someone's spam bot had gone to overdrive and sent over
600 spams to my account (all similar and from the same address, size
about 10K).

Emptying the Junk Mail folder (and blocking the spammers address) meant
that I could again use my account normally and also read the mail from
Hotmail Staff, which told me that if I didn't react before Aug 23,
Hotmail would start "deleting messages (usually older ones from all of
your folders) until your account is smaller than the 2-MB size limit".

Apparently, this is normal behaviour for MS Hotmail, as I managed to
find out in the service conditions. 5 days reaction time, before we
start emptying your account starting from the oldest. The risk?

If someone does not check his/her Hotmail for a week (eg. vacation,
illness), it is very easy to remove all his/her mail from all the
folders by simply sending in too much spam. Including the Junk
Mail-folder into the account size limit makes this kind of
"denial-of-mail" very easy, because mail in a Junk Mail folder isn't
deleted for 14 days from it's arrival.

Fortunately, I don't trust WWW-based email services enough to use them
for anything important but still: wiping out your email box is a
nuisance.

Kimmo Pyykkö, Development Manager, New Communications Services/
  Technology Center  tel. +358 2040 58328


REVIEW: "SSL and TLS", Eric Rescorla

<Rob Slade <rslade@sprint.ca>>
Mon, 20 Aug 2001 10:42:59 -0800

BKSSLTLS.RVW   20010607

"SSL and TLS", Eric Rescorla, 2001, 0-201-61598-3, U$39.95/C$59.95
%A   Eric Rescorla ekr@rtfm.com
%C   P.O. Box 520, 26 Prince Andrew Place, Don Mills, Ontario M3C 2T8
%D   2001
%G   0-201-61598-3
%I   Addison-Wesley Publishing Co.
%O   U$39.95/C$59.95 416-447-5101 fax: 416-443-0948
%P   499 p.
%T   "SSL and TLS: Designing and Building Secure Systems"

The preface states, quite clearly, that this is a work for designers,
programmers, and implementors.  In other words, it's a very technical
book.  Even the preface, though, is written with a clarity that is
unusual, and refreshing, in technical literature.

Chapter one provides some background to communications security and
encryption.  The material is demanding, and is definitely not a
primer.  A number of items are glossed over, but the persistent reader
should be able to glean some very solid explanations of important
concepts.  The "family tree" of SSL (Secure Sockets Layer) is given in
chapter two, with a description of the development steps along the
way.  Chapter three outlines the basic, or most common, mode of SSL,
and then provides details about specific aspects of the algorithms and
data structures used at different points.  Various options and
extensions, for a number of functions, are described in chapter four.
The security of the SSL system itself, as opposed to the security it
provides for transactions, is thoroughly examined in chapter five.
Chapter six is an examination of performance issues, and the ways in
which execution can, and can't, be improved.

SSL is, of course, only a protocol and not a full application.  Design
considerations for effective use within a system are detailed in
chapter seven, and sample C and Java code for effecting the operations
is given in eight.  SSL was designed for, and is most widely used
with, HTTP (HyperText Transfer Protocol), and chapter nine details the
requirements and difficulties of using the system to secure Web
communications.  Chapter ten uses SMTP (Simple Mail Transfer Protocol)
as an example of the use of SSL to protect other communications
operations.  Finally, Rescorla compares SSL to the major competing
systems of IPsec, S-HTTP (Secure HTTP), and S/MIME.  (It is nice to
see that the author identifies his own potential bias in the debate.)

This book is aimed at a technical audience, and members of that group
will undoubtedly welcome it.  However, the lucid presentation, and
range of security concepts covered make this a useful reference for
many others.  Those involved in online commerce and the necessity to
secure transactions over insecure links will find solid discussions
addressing those issues.  Security analysts and practitioners may be
challenged to look into the internals of systems generally examined
only at a superficial level.  And anyone interested in the security of
the Internet will find a clear and fascinating review of its
underpinnings.

copyright Robert M. Slade, 2001   BKSSLTLS.RVW   20010607
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


Dependable Systems and Networks DSN-2002 Call for Contributions

<Anup Ghosh <aghosh@cigital.com>>
Thu, 23 Aug 2001 08:31:18 -0400

The International Conference on Dependable Systems and Networks (DSN-2002)
Bethesda, Maryland, USA    23-26 Jun 2002   http://www.dsn.org
Full papers and workshop proposals due 19 Nov 2001

This conference has combined the International Symposium on Fault-Tolerant
Computing (FTCS), the Working Conference on Dependable Computing for
Critical Applications (DCCA), into the DSN track now called Dependable
Computing and Communications, and in 2002 will also include the
International Performance and Dependability Symposium (IPDS).
See www.dsn.org for submission information.  [PGN-ed for RISKS]

Please report problems with the web pages to the maintainer

Top