precedence: bulk

precedence: bulk
Subject: RISKS DIGEST 19.47

RISKS-LIST: Risks-Forum Digest Weds 26 November 1997 Volume 19 : Issue 47

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: *Happy Thanksgiving* today to Outlook 97!
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)
Abridged info on RISKS (comp.risks)

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

Date: Mon, 24 Nov 97 14:08:02 PST
From: "Peter G. Neumann" <[email protected]>
Subject: California's Deadbeat Dads Database (RISKS-19.12, 19.43)

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.]

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

Date: Tue, 25 Nov 1997 09:01:00 -0800
From: [email protected] (Stevan Milunovic)
Subject: Forbes blames sabotage on hacker

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 [email protected]. PGN]

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

Date: Mon, 24 Nov 1997 07:18:40 -0800 (PST)
From: Robert Dorsett <[email protected]>
Subject: With autopilots, who needs a dog to keep an eye on the pilot?

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]

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

Date: Nov 1997 [exact date clobbered, source lost in original posting]
From: Stevan Milunovic <[email protected]>
Subject: Hacking cost businesses $800 million worldwide

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.

[Source (added in Archive copy): Mike Ricciuti, 6 Jun 1996. NEWS.COM at
http://www.novell.com ]

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

Date: Thu, 20 Nov 1997 17:33:37 -0000
From: Mike Ellims <[email protected]>
Subject: Encryption of electronic mail in the European Community

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). ["html" typo fixed in ARCHIVE copy. PGN]

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 <[email protected]> +44 (0)1223 441 256 [DISCLAIMERS]

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

Date: Wed, 26 Nov 1997 09:49:58 -0500
From: Fernando Pereira <[email protected]>
Subject: Y2K and canned-goods expiration dates

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.

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

Date: Wed, 19 Nov 1997 02:43:41 -0500
From: Yves Bellefeuille <[email protected]>
Subject: Ottawa firm registers "Y2K" as trademark

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 <[email protected]>

[Does that cover "y2k" also? PGN]

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

Date: 24 Nov 1997 11:03:45 GMT
From: "Azeem Azhar" <az!nospam!@nospamxx!nospam!nospam.int>
Subject: Perils of grammar checkers

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

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

Date: Fri, 21 Nov 1997 20:26:57 -0500
From: Steve Crocker <[email protected]>
Subject: Re: Major security flaw in CyberCash 2.1.2

The following message appeared on the net.

> From: Anonymous <[email protected]>
> Subject: Major security flaw in CyberCash 2.1.2
> To: [email protected]
>
> 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 [email protected] +1 703 716 5214

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

Date: Tue, 18 Nov 1997 14:06:05 -0500 (EST)
From: [email protected]
Subject: Another AOL meltdown

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

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

Date: Wed, 26 Nov 1997 10:20:46 -0500
From: "Simson L. Garfinkel" <[email protected]>
Subject: Problems with AOL

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.

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

Date: Tue, 25 Nov 1997 15:53:57 -0600
From: Arthur Flatau <[email protected]>
Subject: Risks of changed URLs

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 <[email protected]>
Austin, Texas http://www.acor.org/diseases/hematology/Leukemia/leukemia.html

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

Date: Mon, 17 Nov 1997 18:53:35 -0500 (EST)
From: David Lesher <[email protected]>
Subject: Risks of blind acceptance

*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."

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

Date: Mon, 17 Nov 1997 16:24:46 -0500
From: Guy J Sherr <[email protected]>
Subject: Re: Outlook for Thanksgiving (Minow, RISKS-19.46)

Robert X. Cringely's article is at:
<http://www.pbs.org/cringely/archive/nov697_main.html> [TYPO FIXED IN ARCHIVE]

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.

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

Date: Tue, 25 Nov 1997 12:40:26 -0800
From: Chris Adams <[email protected]>
Subject: Re: Outlook for Thanksgiving (Minow, RISKS-19.46)

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

Chris Adams <[email protected]>

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

Date: Fri, 21 Nov 1997 11:21:37 EST
From: "Rob Slade" <[email protected]>
Subject: "Halting the Hacker" by Pipkin

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 [email protected]
%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
[email protected] [email protected] [email protected]

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

Date: 17 Nov 1997 15:43:51 -0500
From: Roland Roberts <[email protected]>
Subject: Re: Workaround for the new Pentium flaw

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 [email protected]

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

Date: Mon, 17 Nov 97 20:12:55 GMT
From: [email protected] ("David G. Bell")
Subject: Pentium halting -- who needs DEBUG?

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

The decimal versions of the bytes can be entered on a PC using
<ALT>+<Numeric Keypad> and all you need to start is the command:

copy con kill.com

And finish with ctrl-z to close the file and return to the command prompt.

Or how about a batch file, using a line of the form:

echo <char><char><char><char> > kill.com

<Yorkshire Accent>
And if you tell programmers that today they don't believe you.
</Yorkshire Accent>

People often forget what can be done with batch files that use only
standard shell commands, and I wouldn't be surprised if the same can be
done with Unix-like operating systems.

David G. Bell -- Farmer, SF Fan, Filker, Furry, and Punslinger..

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

Date: Mon, 17 Nov 1997 22:50:30 PST
From: [email protected] (Leonard Erickson)
Subject: Re: New Pentium flaw (someguy, RISKS-19.46)

[email protected] 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) [email protected]

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

Date: 18 Nov 1997 14:47:39 GMT
From: Stanley@@nr1.ottawa.istar.net (Robert Stanley)
Subject: Re: New Pentium flaw (someguy, RISKS-19.46)

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 -- [email protected]

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

Date: 18 Nov 1997 11:15:21 -0000
From: Nick Rothwell <[email protected]>
Subject: Re: New Pentium flaw (Strayer, RISKS-19.46)

> 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

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

Date: Tue, 18 Nov 1997 09:49:00 +0200
From: "Pekka Pietik{inen" <[email protected]>
Subject: Re: Pentium Fix?

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]

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

Date: 1 Apr 1997 (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
[volume-summary issues are in risks-*.00]
[back volumes have their own subdirectories, e.g., "cd 18" for volume 18]
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 19.47
************************