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 31

Sunday 1 April 2001

Contents

Windows 2000 source code
Mark Thorson
Foot-and-mouth virus propagation
PGN
Upcoming time-change risks
Alan Wexelblat
More self-inflicted defense difficulties
PGN
Classification of the Three Mile Island accident
Andrew Raybould
Re: German armed forces ban MS software
Ralf Bendrath
What they can do with your SSN
Ian Macky
Re: Serious new California drivers license ID risk
Tom Goltz
John Noble
Book: Security Engineering, Ross Anderson
PGN
Invitation to the First "PFIR Future of the Internet Workshop"
Lauren Weinstein
Info on RISKS (comp.risks)

Windows 2000 source code

<Mark Thorson <mmm@winery.garlic.com>>
Tue, 20 Mar 2001 17:20:38 -0800

Microsoft Corp.'s decision last week to give its 1,000 top U.S. enterprise
customers access to the Windows 2000 source code has been sharply criticized
by smaller customers.  [Source: eWeek (formerly PCWeek), "Windows Source
Code Deal: Not For All", March 12, 2001, page 20]

  ... even more concern was raised by its implementation language,
  Microsoft Basic.  ``Most of our programmers haven't used Basic since
  college,'' said an IT manager at a Fortune 500 insurance company, ``most OS
  guys don't consider it [Basic] to be a serious implementation language.''

  Mike Conelrad, a senior programmer at an enterprise solution provider
  based in Kentucky, said he is disappointed that Microsoft has only chosen
  to release 'desimonyzed' source code.  ``The original variable names have
  been replaced with code names like A002134,'' according to Conelrad.
  ``That tells me absolutely nothing about the variable.  But with a name
  like wParam, at least I know that the variable is word length.''

  ``Some of the variable names were unacceptable,'' said Microsoft
  spokesperson Lirpa Loof.  ``They used trademarks improperly and had other
  defects which were simply not acceptable in any Microsoft product.''
  Sources close to the Windows 2000 development team indicate that the
  defects include references to Microsoft founder Bill Gates and other
  officers of the Redmond-based company.


Foot-and-mouth virus propagation

<"Peter G. Neumann" <neumann@csl.sri.com>>
Sun, 1 Apr 2001 01:02:03 PST

This bit of satire is very cute.  Unfortunately, its copyright keeps us from
reproducing it here.  Hopefully the given URL will persist.  [This item is
noted courtesy of Mark Brader.]

  Foot-and-mouth believed to be the first virus
  unable to spread through Microsoft Outlook
  http://www.satirewire.com/news/0103/outlook.shtml


Upcoming time-change risks

<Graystreak <wex@media.mit.edu>>
Wed, 21 Mar 2001 10:45:28 -0500

  [Sorry I could not get this out BEFORE the First of April,
  as an early warning.  But it is still timely.  PGN]

I foresee a rash of social engineering set to happen in a few days.

In the USA we change to Daylight Savings Time (spring ahead) shortly after
the equinox.  By 1966 law, we begin observance on the first Sunday in
April, though Congress has a history of mucking about with that date.

This year, that also happens to be the first day in April.  In the US (and
other countries?) there is a long tradition of practical joking, social
engineering, and otherwise just plain messing with people on or around
April first.

I can see that this confluence is going to cause some amount of confusion,
as some people automatically disbelieve any official-seeming announcement
or notice that comes out on or in reference to April 1.  Exchanges of the
form "Don't forget to set your clocks forward" followed by "yeah, right,
funny guy" will likely occur.

Most probably the incidents and losses will be minor and more likely
embarrassing than damaging; however, if I was going to try some kind of
social engineering feat I'd try to structure it so that it seemed an April
Fool's prank if I was caught.

--Alan Wexelblat

P.S. http://www.standardtime.com/ provides a good explanation of why DST
exists and why it's no longer useful.


More self-inflicted defense difficulties

<"Peter G. Neumann" <neumann@csl.sri.com>>
Thu, 29 Mar 2001 14:57:22 PST

On 26 Mar 2001, two U.S. F-15 jets disappeared over Scotland, 45 minutes
after takeoff, each with just the pilot on board.  One plane was later
discovered near the 4,296-foot summit of Scotland's Ben Macdhui, in highest
range in Britain.

Also on 26 Mar 2001, a U.S. Army RC-12 reconnaissance plane crashed near
Nuremberg, Germany, killing its two pilots.

In all, 58 military people were killed in the 12 months ending on 30 Sep
2000 (including 19 aboard the V-22 Osprey in April 2000, but not the four
marines killed on 11 Dec 2000, noted in RISKS-21.14).  Nevertheless, this
was reportedly the lowest military accident rate (1.23 per 100,000 flight
hours) ever recorded.  [Source: AP item, 28 March 2001]

Also, a German military helicopter crashed in Peppen, Germany, on 27 Mar
2001, killing four.

Incidentally, RISKS has not previously noted the most unfortunate recent
U.S. submarine exercise that resulted in the sinking of a Japanese fishing
vessel.  Although the circumstances of that incident are still under
investigation, human mistakes seem to have been much more critical than any
direct implications of the computer-communication technology.  However, that
is of course a common thread among many of the life-critical incidents
reported in RISKS.


Classification of the Three Mile Island accident

<"Andrew Raybould" <arayboul@siac.com>>
Mon, 26 Mar 2001 10:52:01 -0500

This week marks the 22nd anniversary of the Three Mile Island accident, and
while reflecting on that event, it occurred to me that describing it as a
Loss of Coolant Accident (LOCA) doesn't really capture its true nature.
Fundamentally, it was what might be called a Loss of Comprehension Accident:
a minor and correctable problem became the accident it was because neither
the plant's operators, nor the increasingly-senior engineers and managers
brought in as the situation deteriorated beyond recovery, understood what
was happening.

This sort of problem has probably been with us since the development of
organized warfare, but it has increasingly become an issue for ordinary life
as complex control systems have proliferated, starting with railroad
switching and signaling. There is, I understand from this forum and
elsewhere, some concern over whether today's pilots can fully understand
their increasingly-complex airliners (I recall a news item in which the
interviewee quoted pilots as saying things like "why did it do that?" "what
will it do next?" "how can we make it do..."). As the hardware becomes more
reliable, this type of accident becomes relatively more prevalent.

Also, I also strongly suspect that this is a major cause of software
development failures: my experience suggests that projects fall apart at
that point where the level of detail exceeds the developers' cognitive
skills. If so, then the solution will not be found in ever more detailed
procedures and standards; we must pay attention to the abstract reasoning
and language skills that are necessary for a group of developers to
understand, individually and collectively, what it is that they are doing.

Andrew Raybould   andy.raybould@att.net


Re: German armed forces ban MS software (McVay, RISKS-21.30)

<Ralf Bendrath <bendrath@zedat.fu-berlin.de>>
Sat, 24 Mar 2001 03:16:12 -0600

This news is old and wrong - the German armed forces immediately told the
press that they still use Microsoft products. Actually they just bought a
general licence for MS standard office applications half a year ago.  They
even use Lotus Notes, which is known for the "work factor reduction field"
in its encryption keys - and these are known to the NSA. But the Bundeswehr
is not that stupid - they just put everything through hardware encryption
(as far as I remember from Siemens) additionally.  I only have a German
article on this update, sorry.

Ralf Bendrath  Listowner Infowar.de  http://userpage.fu-berlin.de/~bendrath

Update: Bundeswehr setzt weiter auf MS-Software (tecChannel.de, 19 Mar 2001)

Das Verteidigungsministerium hat gegenueber tecChannel.de einen Bericht des
Nachrichtenmagazins Der Spiegel dementiert, wonach die Bundeswehr kuenftig
in Computern keine Software von Microsoft mehr einsetzen werde. Wie
berichtet, heisst es in dem Artikel "Die Angst der Deutschen vor
amerikanischer Spionage", der amerikanische Geheimdienst NSA habe nach
Erkenntnissen deutscher Sicherheitsbehoerden Zugriff auf alle
wichtigenQuellcodes von Microsoft Dadurch koenne er auch verschluesselte
Daten lesen. Das Verteidigungsministerium wolle daher in sensiblen Bereichen
kuenftig nur noch Verschluesselungstechniken der deutschen Firmen Siemens
und der Telekom einsetzen, um seine Geheimnisse zu schuetzen, so der
Spiegel.  Ein Sprecher des Bundesministeriums fuer Verteidigung hat den
Spiegel-Bericht jetzt gegenueber tecChannel.de dementiert. In einem Fax, das
die Redaktion vor wenigen Minuten erreichte, heisst es: "Die Behauptung, die
Bundeswehr werde in sensiblen Bereichen kunftig keine Software der Firma
Microsoft mehr verwenden, ist falsch." Die Bundeswehr habe demnach erst vor
einem halben Jahr einen Generallizenzvertrag ueber die handelsueblichen
Softwareprodukte mit Microsoft abgeschlossen. "Die Bundeswehr beabsichtigt,
diese Produkte auch weiterhin einzusetzen", so der Sprecher weiter. Er
betonte, dass sensible Daten im IT-Bereich der Bundeswehr zum einen durch
Firewalls gesichert seien. Zum anderen setze die Bundeswehr auf
Verschluesselungstechniken, "die durch das Bundesamt fuer Sicherheit in der
Informationstechnologie (BSI) zugelassen sind.  Deren Schutzfunktionen
arbeiten unabhängig von der benutzten Software", heisst es in der
Mitteilung. (jma)


What they can do with your SSN

<Ian Macky <imacky@us.oracle.com>>
Sat, 24 Mar 2001 14:07:52 -0800 (PST)

In March of this year, 2001, in which it is proven that we are all very
smart monkeys indeed, I received my monthly mortgage statement and noticed
in the bottom IMPORTANT MESSAGES section:

    YOUR MORTGAGE INFORMATION IS NOW AVAILABLE ONLINE!  [Note, feel
    dreadful sort of arousal here, like anticipation of being screwed]
    JUST FOLLOW THESE STEPS: 1. GO TO WWW.xyz.COM [Censored]  2. CLICK
    ON "MY HOME LOAN ACCOUNT"  3. ENTER YOUR ACCOUNT NUMBER  4. ENTER
    YOUR PASSWORD (YOUR STATE ABBREVIATION & THE LAST 4 DIGITS OF THE
    PRIMARY BORROWER'S SOCIAL SECURITY NUMBER, EXAMPLE NY1234).

On this same piece of paper are my account number and state abbreviation.

Yet ``it's unlikely and unusual for someone who has your Social Security
number to be able to do anything with it.  Normally, financial institutions
require additional information.''

"Unlikely", "unusual".  Pretty squirmy.  And that additional information
sure was hard to come by.

BTW, my mortgage holder is a colossus whom everyone has heard of.  Large
body does not equal large brain when it comes to corporations-- the area
of the pyramid's tip remains constant (and small!).


Re: Serious new California drivers license ID risk (Cornell, R-21.29)

<Tom Goltz <tgoltz@QuietSoftware.com>>
Sun, 25 Mar 2001 20:48:30 -0500

  [From Dave Farber's IP distribution]

Ironically, the fake doesn't even have to be very good.
A couple of facts that you may find interesting:

I am white.  I have held a California driver's license in the past, but
that license has been inactive for over two years since I established
residency in another state.

In October of last year, a black male obtained a fake California driver's
license with my name on it and his picture.  The driver's license ID # he
used belongs to a white female.  The address is a Commercial Mail
Receiving Agency in Costa Mesa CA, which the state doesn't normally
allow.  The fake also contained two spelling errors.

This person used this ID and my social security number to open a dozen
different credit accounts in my name at various locations around the Los
Angeles area.  He was using a cell phone with a phone number based in the
603 area code as his residence phone.

If anyone had bothered to look, just about everything about this guy
screamed fraud, yet he managed to steal $15,000 worth of merchandise
(mostly jewelry).

Out of all these people who were supposed to be checking this information,
only TWO found problems.  One was a used car dealer who became suspicious
when the check this guy gave for the down payment proved to be
bogus.  They refused to give the guy the car, but didn't bother to pursue
the matter with the police.  The other was store security at a Costco in
Las Vegas, who tracked me down in New Hampshire and informed me that I had
a problem.  They detained the man, and turned him over to the police.

Sadly, the most he's going do is a couple of years probation - he didn't
actually steal anything in Las Vegas, and the identity theft, although a
crime in NV is not sufficient to assure jail time by itself.  I discussed
the matter of extraditing the varmint to California with Las Vegas police,
but they told me that it was unlikely that California would bother for
something that would only net the offender probation there as
well.  According to the LV police detective, in California, you have to be
charged with stealing over $50,000 before you'll do any jail time.

It's no wonder this crime is exploding...it's low risk, extremely
profitable, and trivial to implement.

Oh yes...how did he get my name and social security number?  He told the
Las Vegas police that he purchased the information on the street for $500.

Tom Goltz, Software Engineering Services  (603) 594-9922


Re: Serious new California drivers license ID risk (Cornell, R-21.29)

<John Noble <jnoble@dgsys.com>>
Mon, 26 Mar 2001 06:17:46 -0500

  [From Dave Farber's IP distribution]

I'm a recovering bank lawyer who hasn't had a serious lapse in nearly ten
years, but I find I can't help myself. The account of the fraud perpetrated
with a forged drivers license and the supposed complicity of Wells Fargo and
California law is misinformed and misinforms your subscribers. It has
nothing to do with the real risks identified in the Risk Digest item he
points to.

Although drivers licenses are increasingly designed to be more difficult to
duplicate than they used to be, you can forge anything with the right
equipment. There is nothing new about that. People have been forging
identification and cashing bad checks since they invented banks. Whatever
the problem with the CA license, it is not obvious how it contributes to the
fraud Mr. Cornell describes. The fact that the lic. no. and DOB is recorded
on a magnetic strip instead of printed on the license only makes it that
much harder to discover, and that much harder to duplicate. Mr. Cornell
indicates that he wants one without a photo. How does that help? Cornell's
photo-free driver's license is only going to prevent him from cashing
checks. It isn't going to stop someone else with a forged license that does
have a picture unless he can find a bank that requires DNA testing to cash a
check.

Mr. Cornell's description of the CA Commercial Code leaves out the good
parts. An account may be debited if the item was "properly paid," i.e.
"authorized" in fact. If the item was not authorized, the customer need only
notify the bank within a reasonable time after receiving his statement to
have the account re-credited -- the burden is on the bank to prove that the
endorsement was genuine, which is impossible. Banks typically ask the
customer to sign an affidavit; and they pull the video sequence of the
transaction at the teller window to confirm that the customer did not cash
the check himself (the unlikely exception to the impossibility of proving
the endorsement was genuine). Mr. Cornell points to Code provisions that
require the victim to "prove" that the bank failed to exercise "ordinary
care." But the provision only applies to losses caused by the customer's
failure to review his bank statement and report an unauthorized debit within
a reasonable time. In effect the bank is strictly liable for unauthorized
debits during the first 6-8 weeks on little more than the customer's
insistence that they were unauthorized.  But if the customer doesn't look at
his statement and report the unauthorized transactions disclosed on the
statement, the bank's liability is cut off and the customer is stuck with
the additional losses. The reasons for this are obvious. Only the customer
is in a position to know that the debit was unauthorized. If he doesn't look
at his statements, and the same guy is cleaning him out month after month,
whose fault is that?  In addition, the law has to take into account the
possibility that the customer is having his own checks cashed by a third
party.

If Cornell has scoured the internet without finding it mentioned, it is
because it is relatively rare. This is a risky, complicated, inefficient and
finally stupid way to steal money. Someone has to make the ID (holograms,
magnetic strips encoded with the drivers lic. no. and DOB); then stand at
the teller's window in front of a camera posing for the wanted
poster. Moreover, when you cash a check that bounces, the bank doesn't wait
until the end of the statement cycle to let you know about it. They send you
a letter. You would need to ignore those letters, as well as your bank
statement, to lose the tens of thousands of dollars Cornell reports. When
the forger cashes a check for which the the bank isn't liable, 6-8 weeks
after he cashed the first check, the forger needs to assume that the victim
has ignored the letters and statement -- because otherwise he's
busted. Anybody who has your bank account no. can far more easily create
checks that carry your name and account number. He doesn't need your drivers
lic. no., DOB, or soc. sec. no. for that. He just draws against your account
on checks coded with your account no.; deposits them in a straw account;
withdraws the funds and closes the account before your statement goes out;
and moves on to another bank and another victim because he has to assume you
reported the fraud. He can do all that without ever having his picture taken
for either a fake drivers license or a wanted poster. He doesn't have to
stand at the teller window in your bank wondering whether he's about to get
busted because you reviewed your statement and reported the fraud, and his
picture from the videotape has been circulated to the tellers and security
personnel. He can move the money and close the account from the safety of
his apartment using his computer.  The moral of the story: review your bank
statements -- it's part of the deal.  John Noble


Book: Security Engineering, Ross Anderson

<"Peter G. Neumann" <neumann@csl.sri.com>>
Thu, 29 Mar 2001 16:12:17 PST

Ross Anderson
Security Engineering: A Guide to Building Dependable Distributed Systems
John Wiley & Sons
March 2001
xxviii+612 pp.
ISBN 0-471-38922-6

This book is an enormous undertaking.  The chapter titles suggest the
breadth of coverage.

Part 1 (basic concepts)
 1. What is security engineering
 2. Protocols
 3. Passwords
 4. Access controls
 5. Cryptography
 6. Distributed systems

Part 2 (important applications)
 7, Multilevel security
 8. Multilateral security
 9. Banking and bookkeeping
10. Monitoring systems
11. Nuclear command and control
12. Security printing and seals
13. Biometrics
14. Physical tamper resistance
15. Emission security
16. Electronic and information warfare
17. Telcom system security
18. Network attack and defense
19. Protecting e-commerce systems
20. Copyright and privacy protection

Part 3 (organizational and policy issues)
21. E-policy
22. Management issues
23. System evaluation and assurance
24. Conclusions

Although there are other books that delve into greater detail on specific
topics, this book should be extremely useful to many people who need the
overall system perspective that Ross provides.

Ross's preface concludes with this sentence:

  "I believe that building systems that continue to perform robustly
  in the face of malice is one of the most important, interesting,
  and difficult tasks facing engineers in the twenty-first century."

I could not agree more, although I would add that building systems to
perform robustly in the face of arbitrary adversities (accommodating power
and communication losses, rodents, bad software engineering, user errors,
etc. -- that is, not merely accounting for malice) is even more challenging.
Many systems in common use tend to fall apart all by themselves -- without
any malice!


Invitation to the First "PFIR Future of the Internet Workshop"

<Lauren Weinstein <lauren@pfir.org>>
Sat, 31 Mar 2001 16:13:40 -0800 (PST)

     	         "PFIR Future of the Internet Workshop"

     From: Lauren Weinstein 	           Peter G. Neumann
           lauren@pfir.org        and      neumann@pfir.org
	   lauren@vortex.com		   neumann@csl.sri.com

	   Co-Founders, PFIR - People For Internet Responsibility
	   http://www.pfir.org

Greetings.  People For Internet Responsibility (PFIR), in conjunction with
the ACM Committee on Computers and Public Policy, is pleased to announce the
first "PFIR Future of the Internet Workshop," to be held on the weekend of
May 5 and 6, 2001, at the Culver City Veterans Memorial Complex, just
minutes from Los Angeles International (LAX) airport.  Vortex Technology of
Woodland Hills, California is handling the event logistics.

Information about PFIR, and the current PFIR position papers, are available
at: http://www.pfir.org.

This very small event will bring together for open discussions some of the
Internet's most important "doers" (including Dave Farber, former Chief
Scientist for the FCC and a founding member of the PFIR Board of
Directors).  The workshop is aimed at encouraging discourse with and among
the persons who have not only been responsible for helping to get the
Internet (and its ancestor ARPANET) to the level we know today, but are also
leading in doing the actual work of helping to guide the Net's future.

The workshop (which we want to limit to around 40 attendees) will be
interdisciplinary in focus.  It will also be informal, low-key, basically
utilitarian, and largely off-the-record.  There will be no formal paper
presentations, no exhibits, and while we expect attendance by one or two
major technology reporters, they will be coming mainly as individual
participants and will have agreed not to report on the content of
off-the-record discussions.

Because space will be limited, and we wish to encourage a diversity of
attendees (in terms of interests, specialties, and geography), we cannot
guarantee that everyone who wishes to attend will be able to do so.  In such
a circumstance, we'll choose among prospective attendees in a manner that
will hopefully enhance the usefulness of the workshop for everyone concerned.

Unless otherwise prearranged in particular cases, all attendees must be
registered in advance of the event.

A framework agenda of the conference will be discussed via e-mail among
participants during the weeks before the event, but it is expected that a
variety of the topics listed in the PFIR Issues document
(http://www.pfir.org/issues) will be of interest.  The agenda will be
subject to change at the workshop as participants see fit.  The Internet is
of course an international medium, and international issues should be of
significant importance in the discussions.  Any topics of relevance to the
Internet, from domain names to governmental controls, from censorship to
intellectual property protections, from infrastructure to law enforcement,
and any others of interest, will be fair game during our discussions.

As Internet-related issues have come to pervade ever more aspects of our
society, reasoned discourse regarding many of these issues has increasingly
been drowned out by a sea of emotional e-mail interactions and hardening
uncooperative positions.  This workshop will present an opportunity to meet
face-to-face for two days of intelligent conversations as human beings, as
we try to chart some possible solutions and courses for the range of
difficult challenges the Internet (and society's reactions to the Net) have
presented to us.

We're trying to keep the workshop as simple as possible.  We'll be charging
a small registration fee (about $85) to help defray costs.  This amount will
include continental breakfast and a lunch both days.  There are a number of
reasonably-priced hotels in the area.  L.A. being what it is, you'd
probably want to rent a car, though some car-pooling arrangements can
possibly be worked out if there is interest.  The workshop will run from
9 AM to 4:30 PM on Saturday May 5, and from 9 AM to 3:00 PM on Sunday May 6.
We'd like to handle most or all of the registrations before the actual event
if possible.  Details on this and other related information (hotel lists,
etc.) will be provided later.

If you're interested in attending, or if you have other questions about the
workshop purpose, agenda, or other associated matters, please send an e-mail
note to:

   workshop@pfir.org

Please be sure to mention your areas of interest and specialties relating
to Internet issues.

We'd also be happy to chat by phone at the numbers listed below.  Questions
regarding ongoing workshop operational issues (registrations, information
about the area or other assistance and questions, etc.) should be directed
to Susie Hirsch (susie@pfir.org).  You can contact Susie by phone
at: (310) 737-1739.

We hope that you'll consider attending!  Please let us know if you're
interested, at your earliest opportunity, and we'll keep you on the
information list.  Because this is a small event, every attendee is
especially important, and we're doing our utmost to bring together a
fascinating and somewhat eclectic group of "movers and shakers" who, working
together, can help the Internet better serve everyone, everywhere.

We look forward to hearing from you.  Thank you very much.

Lauren Weinstein
lauren@pfir.org or lauren@vortex.com
(818) 225-2800
Co-Founder, PFIR - People For Internet Responsibility - http://www.pfir.org
Moderator, PRIVACY Forum - http://www.vortex.com
Member, ACM Committee on Computers and Public Policy

Peter G. Neumann
neumann@pfir.org or neumann@csl.sri.com
(650) 859-2375
Co-Founder, PFIR - People For Internet Responsibility - http://www.pfir.org
Moderator, RISKS Forum - http://catless.ncl.ac.uk/Risks
Chairman, ACM Committee on Computers and Public Policy

Please report problems with the web pages to the maintainer

Top