Subject: RISKS DIGEST 18.52

RISKS-LIST: Risks-Forum Digest  Saturday 12 October 1996  Volume 18 : Issue 52

  FORUM ON RISKS TO THE PUBLIC IN COMPUTERS AND RELATED SYSTEMS (comp.risks)
  ACM Committee on Computers and Public Policy, Peter G. Neumann, moderator

***** See last item for further information, disclaimers, caveats, etc. *****

 Contents:
Rats take down Stanford power and Silicon Valley Internet service (PGN)
Punch-card ballots overturn primary election result (Dave Tarabar)
Pyramid schemes on the Internet (PGN)
Smartcard security and tampering vulnerabilities (Ross Anderson)
Are Laptops Risky at 30,000 Feet? (Edupage)
"Practical UNIX and Internet Security" by Garfinkel/Spafford (Rob Slade)
Novell and CC:Mail risk (John Colucci)
Maybe your secure Mac isn't as secure as you think (Carl Maniscalco)
Accidental denial-of-service to subscriber [email protected] (Nick Rothwell)
ZIP Code Causes Misaddressing of Packages (Frank Markus)
``Return to sender'' (Dik Winter)
Re: Another mail-forwarding problem (Tony Lima)
A Postmature Date on A Premature Comment (Peter Ladkin)
CFP Computer Security Foundations Workshop 10 (Simon N. Foley)
Abridged info on RISKS (comp.risks)

----------------------------------------------------------------------

Date: Sat, 12 Oct 1996 13:48:41 -0700
From: "Peter G. Neumann" <[email protected]>
Subject: Rats take down Stanford power and Silicon Valley Internet service

Two rats crawled through an underground cable conduit into a cabinet of
power switching gear adjacent to the Stanford University cogeneration plant,
and caused an explosion that cut off power to the Stanford area beginning
around 7:30pm on Thursday evening, 10 Oct 1996, and continuing until 3:30pm
Friday afternoon.  The BBN Planet hub (Internet Point of Presence, or PoP)
at the Stanford University Data Center remained in operation for a few hours
on standby battery power, but then gave out around 9pm Thursday; it came
back up around 4:30pm, an hour after Stanford restored power.  To name just
a few, Bay-Area BARNet users at Stanford, U.C. Berkeley, Apple, Sun,
Hewlett-Packard, Lawrence Livermore (partially), and SRI were cut off from
the Internet.  The *Los Angeles Times* and *San Francisco Chronicle* on-line
sites were also off the air.  Because I had no Internet access yesterday, I
held up RISKS-18.52 -- thus enabling me to include this item adding to our
RISKS archives collection of rodent-induced outages.  (Long-time readers
recall that SRI alone has contributed four fresh-fried squirrels resulting
in power outages.)  [Sources: On-line messages and a front-page *San
Francisco Chronicle*, 12 Oct 1996 item]

Evidently, the horse is out of the BARNet, and the rats found the weak lynx.
They sure put a ro-dent in the day for many BayAreans.  Perhaps your mouse
will click on a tale of its own.  At any rate, this is just one more saga in
the weak-link-in-the-infrastructure department.  But I'm surprised that
power-system technology has not found a way to develop rodent-tolerant
circuits.

 [With SysAdmins and others pacing the halls at SRI waiting for whatever,
 Doug Moran remarked that keeping around a few fresh-frozen electrofried
 rodents is allegedly standard practice for purveyors of power; it is then
 very easy to have a fallback alibi when no other cause can be found.]

------------------------------

Date: Thu, 10 Oct 1996 10:24:47 -0400
From: [email protected] (Dave Tarabar)
Subject: Punch-card ballots overturn primary election result

Punch-card ballots have been responsible for the uncertainty about the
result of the Democratic Primary for the 10th Congressional District of
Massachusetts.

The election was held on 17 Sep 1996.  The official count was not released
until two days later.  Philip Johnston was said to have defeated William
Delahunt by 266 votes out of 49,371 ballots cast.  Delahunt called for a
recount, citing some 1000 punch-card ballots that were counted as blanks by
the mechanical vote counter.  On 2 Oct, the results of the recount were
announced that showed Johnston the winner by 175 ballots.

During the recount, the questioned ballots were examined by a human election
official.  The legal standard requires that the intent of the voter should
govern the vote count.  Thus if a ballot is not punched through, but is
indented, then a vote should be counted.

Delahunt took the dispute to state court.  A state court judge examined 956
ballots in chambers and ruled that only about 50 were actually blank.  On 4
Oct, the judge declared Delahunt the winner by 108 votes.  On 8 Oct, the
Massachusetts Supreme Court upheld the decision, giving Delahunt less than a
month to gear up for the general election.

It will be interesting to see what changes will be made for the general
election.  Punch-card ballots are used by 35 municipalities in Massachusetts
(including mine).  Hopefully there will be more education of voters to be
sure that they completely punch out the perforation when they vote.

Dave Tarabar  SystemSoft Corp.  2 Vision Drive  Natick, MA  01760
508 647-2952   [email protected]

 [This separates the "cent huit"[*] from the chaff (I'm punchy today)!
 [* I seldom explain my obscurer puns, but this one is 108 en francais.]  PGN]

------------------------------

Date: Thu, 10 Oct 96 13:03:51 PDT
From: "Peter G. Neumann" <[email protected]>
Subject: Pyramid schemes on the Internet

Are you being flooded with spams and scams the way I have been?
(With address variations on both my own account and RISKS, I
often get at least FOUR copies of a given spam.)

The National Consumer League has issued a list of the top five types of
Internet scams, based on complaints reported to Internet Fraud Watch.  On
top are (1) pyramid scams, such as Fortuna Alliance L.L.C. conning folks
into paying $250 to $1750 by promising them $5000 per month when others
enrolled.  Next in line are (2) bogus Internet-related services, (3)
misleading equipment sellers, (4) fraudulent business opportunities, and (5)
work-at-home offers.  The Internet Fraud Watch can be reached in the U.S. at
1-800-876-7060 <[email protected]> <http://www.fraud.org>.  [Source: *San
Francisco Chronicle*, 10 Oct 1996, B3.]

Avoid a pyramid-life crisis.  Don't be a sucker.  Caveat emptor.

------------------------------

Date: Thu, 10 Oct 1996 12:24:17 +0100
From: Ross Anderson <[email protected]>
Subject: Smartcard security and tampering vulnerabilities (RISKS-18.50)

The smartcard security weakness [to interference phenomena] reported by
Bellcore [Boneh/DeMillo/Lipton, noted in RISKS-18.50] is well-known in the
TV-hacking community; power and clock glitches can be used to read out the
memory contents of a number of smartcards. The typical modus operandi is to
attack a loop in the card's software that reads out a series of memory
addresses to the serial port. If a glitch can be found that causes the
loop-variable decrement instruction to be wrongly decoded, then the entire
contents of memory may be output.

Ross

 [Stay tuned for a paper by Ross and Markus Kuhn of Purdue's COAST
 Lab that they will present at the Usenix Electronic Commerce
 conference in November.  Note that the A-K techniques for analyzing the
 attack results are completely different from those of B-D-L, but the
 triggering events can be similar.  PGN]

------------------------------

Date: Thu, 10 Oct 1996 16:35:06 -0400 (EDT)
From: Edupage Editors <[email protected]>
Subject: Are Laptops Risky at 30,000 Feet? (Edupage, 10 Oct 1996)

A new report by RTCA Inc., a nonprofit group that advises the airline
industry, recommends tougher restrictions on the use of portable electronic
devices during "all critical phases of flight."  Some experts are even
calling for a complete ban on all devices during flight.  Currently, the
Federal Aviation Administration leaves that decision up to individual
airlines.  In addition, the report recommends a total ban on all devices
that transmit radio waves, such as a pager that automatically acknowledges
receipt of a message by sending one back, or a laptop equipped with a
wireless modem.  Studies have shown that some of the strongest
electromagnetic fields come from laptop computers, as the shielding that
protects against unintended radio emissions tends to deteriorate over time.
A laptop with a 90-Mhz microprocessor can leak radiation at that frequency
as well as at higher, so-called harmonic frequencies, interfering with a
plane's navigation and communications capabilities.  (*Business Week*,
14 Oct 1996, p90)

------------------------------

Date: Thu, 10 Oct 1996 10:56:23 EST
From: Rob Slade <[email protected]>
Subject: "Practical UNIX and Internet Security" by Garfinkel/Spafford

BKPRUISC.RVW   960619

"Practical UNIX and Internet Security", Simson Garfinkel/Gene Spafford, 1996,
1-56592-148-8, U$39.95/C$56.95
%A   Simson Garfinkel [email protected] [email protected]
%A   Gene Spafford [email protected]
%C   103 Morris Street, Suite A, Sebastopol, CA   95472
%D   1996
%G   1-56592-148-8
%I   O'Reilly & Associates, Inc.
%O   U$39.95/C$56.95 800-998-9938 707-829-0515 fax: 707-829-0104 [email protected]
%P   1004
%T   "Practical UNIX and Internet Security"

The title is certainly apt.  This book is definitely practical, and if your job
involves system security, at whatever level, this book belongs on your desk.
The expansion of the title is no mere attempt to gain market share: this
edition is twice the size of the old one.

The book is well planned and comprehensive.  While the emphasis and examples
are from the UNIX operating system and Internet protocols, background
information is given on related (and important) topics such as modems and
physical security.  The writing and examples are clear and understandable, and
should present no problems to the intelligent novice, but the additional
material ensures that there is value here even for the UNIX guru.

The six "parts" of the work (plus a set of appendices) present logical
divisions of the topic.  "Computer Security Basics" begins with an introductory
chapter defining computer security, an operating system and UNIX.  It continues
with a discussion of policy and guideline considerations.

Part two deals with the responsibility of the user.  The chapters deal with the
defence of accounts and the protection of data through users and passwords;
user accounts, "groups" and the "superuser"; and details of the UNIX file
system.  Part three looks at the system side of security, with attention to
backups, integrity, auditing, malicious software, and physical and personnel
security.

Part four covers communications aspects.  This is highly important considering
the strengths of UNIX in communications, the use of UNIX machines as bridges
between other proprietary systems, and the participation of UNIX systems in the
Internet.  Chapters are devoted to modems, UUCP, TCP/IP, and Kerberos.  Part
five could be seen as an extension, dealing with advanced network security
topics such as firewalls.

The sixth section begins to move away from strictly technical aspects, and
starts to deal with your response to "security incidents".  This may seem, to
some, either irrelevant or defeatist.  However, it points out an important
attitude to have with respect to security:  assume that, at some point, you are
going to fail--and be prepared.  The chapters here are no less practical than
the foregoing, detailing the discovery of break-ins, denial of service attacks,
and the (U.S.) legal aspects of security.  (I appreciate the authors'
forthrightness at this point:  the chapter is entitled "Computer Security and
U.S. Law", and doesn't assume one legal system fits all.)

A updating and expansion of a comprehensive and dependable classic in the
security field

copyright Robert M. Slade, 1993, 1996   BKPRUISC.RVW   960619

Vancouver      [email protected]        | "Do you get guns with your
Institute for  [email protected]  |  gun magazines?  No.
Research into  [email protected]        |  Do you get viruses with your
User           [email protected]|  virus magazines?  Yes."
Security       Canada V7K 2G6          |               - Kevin Marcus

------------------------------

Date: Wed, 09 Oct 1996 21:18:47 -0700
From: John Colucci <[email protected]>
Subject: Novell and CC:Mail risk

Most folks know that on a Novell network the user is prompted to change
their password every so often for security purposes. CC:Mail on the other
hand is a password eternal system unless of course the user is not so
irresponsible to never change it on their own volition. The Novell/CC:Mail
double password system can be a fairly secure way to insure your mail
account privacy. A trick to access the cc:mail accounts of all the local
network users, bypassing the Novell login password follows. Login as you
normally would using your own account. Go to the N: directory prompt and
edit the hidden file "cc-mail.bat" to delete your user name. Save it and
logout. Now login again and go to the n: prompt. This time when you type
"cc-mail" you are presented with a universal login screen. Type in the users
account name that you want to read. You are then asked for a password which
in this case is usually a very easy guess. The usual last name, wife, dog,
kids, job title, nickname, works in the majority of cases. The sense of
security that the initial Novell login password gives is enough to cause
most people to pick really lame cc:mail passwords. What is REALLY funny is
that the easiest accounts to hack at our company were the managers and
supervisors accounts.

------------------------------

Date: Thu, 10 Oct 1996 12:06:59 -0700
From: [email protected] (Carl Maniscalco)
Subject: Maybe your secure Mac isn't as secure as you think

I recently downloaded a Macintosh shareware game from a reasonably
trustworthy Web site.  After playing it for a while, I decided it was
worthwhile to pay the shareware fee. This particular software author (all
names omitted to avoid unfairly painting anyone as a bad guy) included a
small utility program that allows the user to fill out an on-screen form and
print up an invoice for registration. Imagine my surprise when, upon
launching this registration utility, I found my email address already listed
in the appropriate field!  , Many Mac Internet applications used with
dial-up accounts either can (or in some cases, must) use a freeware control
panel called ConfigPPP. I imagine that this is where the registration
utility got my email address. ConfigPPP stores information about servers,
user names and, if the user so chooses, account passwords in a central
location. These can be automatically polled by savvy Internet applications,
thus making setup of each application simpler.  Since the relevant computer
is my home machine and used only by me, I had stored my PPP dollop account
password in order to save a little time each time I log on.

When I printed up the shareware registration document, there were numerous
lines of bar code printed at the bottom. These bar codes had what they
ostensibly meant printed out in plain text beneath each line; however,
there was no way I could confirm this was the information that the codes
actually contained. For all I knew, they could easily contain my password.
While I doubt very much that the shareware author in this case has done
such a thing, it sure got me thinking about other potential security
breaches. For instance, I imagine that it would be possible for a JAVA
applet to poll ConfigPPP, pull out stored user names and passwords and send
them off somewhere.

I have since deleted my password from ConfigPPP. Other Mac users may want
to reconsider storing passwords on their "secure" computers as well.

--Carl Maniscalco, San Diego, CA--

------------------------------

Date: Thu, 10 Oct 1996 10:52:06 +0000
From: Nick Rothwell <[email protected]>
Subject: Accidental denial-of-service to subscriber [email protected]

This one is gleaned from reading news.admin.net-abuse.misc over the last week.

The Microsoft Network has a user with username "abuse" who now has a full
mailbox. It's full of complaints by Internet users at large about junk mail
from other users at msn.com.

Apart from the denial-of-service consequences for this user, it also means
MSN's administrators are not getting abuse complaints (unless the poor user
is dutifully forwarding them all).

Bottom line: an unfortunate interaction of a newly-established de-facto
standard ([email protected] for compaints about domain.com users) with an
unlikely (although explainable) choice of username.

Nick Rothwell, CASSIEL  http://www.cassiel.com

------------------------------

Date: Thu, 10 Oct 1996 08:04:22 -0400
From: "Frank Markus" <[email protected]>
Subject: ZIP Code Causes Misaddressing of Packages

       Fire Island is a summer resort on a barrier beach off the south
shore of Long Island.  During the summer the various communities on the
island have seasonal post offices that receive their mail from the mainland
post office in Bay Shore (or Bayshore .. but that is another story), NY.
The seasonal post offices do not have individual ZIP codes or ZIP+4
extensions assigned to them.  They are all assigned the same 11706 ZIP code
of the Bay Shore post office.  That office sorts the mail addressed to the
various Fire Island communities and sends it on to the appropriate places.

       Unfortuantely, when one tries to order something for delivery to a
specific community on Fire Island, the "clever" software at the mail order
vendor notices that the community specified is not the same as that for the
ZIP code (Bay Shore) and helpfully changes it.  Once the package arrives in
Bay Shore, there is no way to determine to which of the several Fire Island
communities it should be delivered.  Even when I specify that my community
must be manually entered and checked, it appears that the software either
cannot be overridden or, if manually overridden once, wins in the second
round.

       I have taken to entering the name of my Fire Island community as the
second line of my address after my street address much as one would an
apartment number.  This redundancy usually works but is at best a clumsy
solution to the problem.  And, of course, it is of no use whatever to
seasonal renters who merely specify their name, address, community and ZIP
code -- and are not in the phone book.

------------------------------

Date: Thu, 10 Oct 1996 04:09:22 +0200
From: [email protected]
Subject: ``Return to sender''

We just had a special form of "return to sender".  In order to obtain some
of the benefits alloted to us according to Dutch law, we had to fill in some
forms, put the forms in a pre-printed envelope, enter our address at the
backside and put it in a mailbox.  Much to our surprise the letter came back
a few days later without any notice as to why it came back.  Some study
reveiled the reason.  The Dutch PTT prints in orange the "zip"-code as a
bar-code on an envelope, in this case the code was printed on the backside,
and apparently encoded our "zip"-code, so the person who did the
"zip"-coding apparently had reversed the envelope after cancelling the
stamp.  Nobody in the remaining chain until delivery had seen what was
happening.

This immediately created a new problem: how to get those forms to the
institution where they were meant to go to on time?  Time was short,
and they only accept forms with the pre-printed envelopes and they had
only a postbox address.  Putting the envelope in the mailbox again might
have many different results, return to sender again, delivered with
postage due (the stamps were already canceled, and the institution does
not accept letters that are not properly stamped), or whatever.  Well,
the letter was handed in person at the post office, they heavily crossed
out the orange printed barcode, notices were put on the envelope saying
"this is the sender" and "this is the addressee".  And no, we have not
yet received it back.  We hope it was on time.

dik t. winter, cwi, kruislaan 413, 1098 sj  amsterdam, nederland, +31205924131
home: bovenover 215, 1025 jn  amsterdam, nederland; http://www.cwi.nl/~dik/

------------------------------

Date: Wed, 09 Oct 1996 22:19:00 -0700
From: [email protected] (Tony Lima)
Subject:  Re: Another mail-forwarding problem (Howard, RISKS-18.51)

Back in the days when I was giving dBASE seminars, I used the "stripped
leading zero" as a reason to make fields for U.S. ZIP codes character type
rather than numeric.  At one such seminar in Boston (where 02215 is a common
ZIP code), a participant noted that they'd sent their mailing list to a
Texas company for processing and it had come back with four digit ZIP codes.
Said participant now understood the problem better.  Apparently some
branches of the U.S. postal service don't.

[email protected] (Tony Lima)

  [Typo fixed in archive copy.  U.S., not U.K.  PGN]

------------------------------

Date: Thu, 10 Oct 1996 11:16:47 +0200
From: Peter Ladkin <[email protected]>
Subject: A Postmature Date on A Premature Comment (Ladkin, RISKS-18.51)

Steve Belle pointed out to me that the B757 was introduced in January 1983,
not 1993.  Thanks to Steve for catching the inadvertent typo. Yes, the B757
flew for nearly 13 years with its unblemished accident record.  Peter Ladkin

  [I fixed the typo in the FTP.SRI.COM archive copy.  PGN]

------------------------------

Date: 10 Oct 1996 13:36:11 +0000 (GMT)
From: [email protected] (Simon N. Foley)
Subject: CFP Computer Security Foundations Workshop 10

       Preliminary Call For Papers [Edited for RISKS]
      10th IEEE Computer Security Foundations Workshop
                       June 10-12, 1997
                 Rockport, Massachusetts, USA
             Sponsored by the IEEE Computer Society

This workshop series brings together researchers in computer science to
examine foundational issues in computer security.  We are interested both in
papers that describe new results in the theories of computer security and in
papers and panels that explore open questions and raise fundamental concerns
about existing theories.

Possible topics include, but are not limited to:
  access control       authentication     data and system integrity
  database security    network security   distributed systems security
  security protocols   security models    formal methods for security
as well as foundational issues relating to other critical system properties
and in emerging areas such as mobile computing and executable content.

Submission deadline: 7 Feb 1997

For further information contact:

General Chair                Program Chair             Publications Chair
Jonathan Millen              Simon Foley               Joshua Guttman
The MITRE Corporation        Dept of Computer Science  The MITRE Corporation
Burlington Road,             University College        202 Burlington Road
Bedford, MA 01730-1420, USA  Cork, Ireland         Bedford, MA 01730-1420, USA
+1 617-271-3580              +353 21 902929            +1 617-271-2654
[email protected]                [email protected]         [email protected]

More online information at <URL:http://www.jcompsec.mews.org/csfw.html>.

------------------------------

Date: 15 Aug 1996 (LAST-MODIFIED)
From: [email protected]
Subject: Abridged info on RISKS (comp.risks)

The RISKS Forum is a MODERATED digest.  Its Usenet equivalent is comp.risks.
=> SUBSCRIPTIONS: PLEASE read RISKS as a newsgroup (comp.risks or equivalent)
if possible and convenient for you.  Or use Bitnet LISTSERV.  Alternatively,
(via majordomo) DIRECT REQUESTS to <[email protected]> with one-line,
  SUBSCRIBE (or UNSUBSCRIBE) [with net address if different from FROM:] or
  INFO     [for unabridged version of RISKS information]
=> The INFO file (submissions, default disclaimers, archive sites, .mil/.uk
subscribers, copyright policy, PRIVACY digests, etc.) is also obtainable from
http://www.CSL.sri.com/risksinfo.html  ftp://www.CSL.sri.com/pub/risks.info
The full info file will appear now and then in future issues.  *** All
contributors are assumed to have read the full info file for guidelines. ***
=> SUBMISSIONS: to [email protected] with meaningful SUBJECT: line.
=> ARCHIVES are available: ftp://ftp.sri.com/risks or
ftp ftp.sri.com<CR>login anonymous<CR>[YourNetAddress]<CR>cd risks
or http://catless.ncl.ac.uk/Risks/VL.IS.html      [i.e., VoLume, ISsue].
The ftp.sri.com site risks directory also contains the most recent
PostScript copy of PGN's comprehensive historical summary of one liners:
  get illustrative.PS

------------------------------

End of RISKS-FORUM Digest 18.52
************************

You are viewing proxied material from gopher.quux.org. The copyright of proxied material belongs to its original authors. Any comments or complaints in relation to proxied material should be directed to the original authors of the content concerned. Please see the disclaimer for more details.