Potentially dangerous Pentium bug discovered
Jay R. Ashworth
jra at scfn.thpl.lib.fl.us
Wed Nov 12 03:40:17 UTC 1997
There tends to be a lot of the following sort of stuff that floats
around unattributed, like the email viruses, and such.
The following is documented, attributed, and _is_ something you should
worry about. Please forward this message around your usual
distribution lists. If you work at a company with lots of computers,
you're invited to print this up and give it to the people who manage
them for you.
(If you have lots of computers at your company, and _no one_ to manage
them for you, I'm looking for a new gig; have someone call me. :-)
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
This message was originated 11 November 1997, by jra at baylink.com...
headers have a way of disappearing.
Enclosed are four messages from the RISKS Digest, an email forum on
risks to the public in computers and related systems, which is one of
the oldest standing regular pieces of editory on the Internet.
It documents a recently discovered bug in the Intel Pentium<tm> and
MMX<tm> processors, which allows user-level code to halt the processor.
This is bad because these chips commonly support multi-tasking, and
often multi-user, systems; halting such systems arbitrarily can destroy
users' work. There appears to be no way to work around this problem
that has been discovered as of 11 Nov 97; the only thing I can suggest
is be _exceptionally_ careful about running programs the parentage of
which you're not certain on production machines... which is good
practice, anyway.
The first three messages detail the problem, in increasingly technical
detail, including a program to demonstrate the problem, and one to
search for files containing the deadly instruction; the last message
discusses some of the potential implications, and why we should know
better.
By way of clarification, all processors have a halt instruction. All
current multi-tasking operating systems run the processor in such a
mode that such instructions are not actually executed as a halt;
control is transferred back to the OS. That is: Intel blew it. Badly.
RISKS-LIST: Risks-Forum Digest Tuesday 11 November 1997 Volume 19 : Issue 45
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. *****
------------------------------
Date: Tue, 11 Nov 1997 16:39:41 -0500
From: Chuck Weinstock <weinstock at SEI.CMU.EDU>
Subject: New Pentium flaw
To summarize, according to today's *Wall Street Journal*:
The Pentium and Pentium MMX chips apparently can be halted by a single,
unprotected, instruction. Over 200 million computers with these chips are
expected to be deployed by year-end. My favorite quote from the article is
by Linley Gwennap, editor of *Microprocessor Report* in Sunnyvale, who says
that "most PC users shouldn't be overly concerned since they would only be
affected if they were the target of a malicious attack."
My second most favorite quote came from Tom Waldrop of Intel in Santa Clara
who "confirmed that someone with malicious intent could exploit the flaw to
cause a system to crash. But a hacker would have to have an ability to send
programs to a computer in machine code, rather than the conventional
computer languages that most programmers use." [We all know how hard that
is...actually maybe these days it is, can we count on the fact that few
people know how to write machine code these days?]
Chuck Weinstock
------------------------------
Date: 09 Nov 1997 09:26:39 +0100
From: Torsten Hilbrich <Torsten.Hilbrich at bln.de>
Subject: New Pentium flaw
Yesterday (Nov, 8) I found the following information on the news-ticker
page of the German Heise-Verlag (shortened to the essential information):
> The Pentium in standard and MMX version halts on execution of the
> instruction:
> F0 0F C7 C8
> This code sequence works independent of any memory protection of the
> operating system.
I was able to reproduce this bug on a Pentium 133 system with the following
operating systems: DOS, Windows 95, Linux 2.0.31, and FreeBSD 2.2.x.
I don't know about PentiumPro and Pentium II.
The risk? Every pentium based server with user access for executing
programs can be crashed using this code sequence. Not to mention Trojan
Horses or Active-X controls.
Here is an example program:
unsigned char hang[] = { 0xf0, 0x0f, 0xc7, 0xc8 };
int main()
{
void (*kill)();
kill = hang;
kill();
/* return can be omitted as there is none */
}
More information and example programs for various operating systems
can be found on http://www.ccc.de
Torsten Hilbrich
[Also noted by Jeff Anderson-Lee <jonah at EECS.Berkeley.EDU>
citing an item from Peter Curran in comp.security.unix, 7 Nov 1997. PGN]
------------------------------
Date: Mon, 10 Nov 1997 01:07:34 -0600 (CST)
From: "Steven O. Siegfried" <sos at dial324.skypoint.net>
Subject: New Pentium flaw
New Intel Pentium risk: user mode program locks up system
The following program, when compiled and run in __USER__ mode on any Pentium
(reported as MMX or not, don't know about Pentium II yet) will lock-up the
system.
> char x [5] = { 0xf0, 0x0f, 0xc7, 0xc8 };
> main ()
> {
> void (*f)() = x;
> f();
> }
Any user can execute this program at the lowest level of security provided by
the following operating systems: OS/2, NT, W95, Linux.
When I tried it, I could _only_ recover by power-cycling my box.
The following perl script, courtesy of Sam Trenholme via the security
mailing list at Redhat Software is reported to find _all_ occurences of this
code sequence on systems running Linux. (It found my bomb program after I
used it to kill my system as a test.) It can probably be adapted for use on
other operating systems.
> #!/usr/bin/perl
> # Source: Sam Trenholme via linux-security at redhat.com mailing list.
> # There is no known software fix to the F0 0F C7 C8 bug at this time.
> # usage: $0 dir
> # Where dir is the directory you recursively look at all programs in
> # for instances of the F0 0F C7 C8 sequence.
> # This script will search for programs with this sequence, which will
> # help sysadmins take appropriate action against those running such
> # programs.
> # This script is written (but has not been tested) in Perl4, to
> # insure maximum compatibility .
> sub findit {
> local($dir,$file, at files,$data) = @_;
> undef $/;
> if(!opendir(DIR,$dir)) {
> print STDERR "Can not open $dir: $!\n";
> return 0;
> }
> @files=readdir(DIR);
> foreach $file (@files) {
> if($file ne '.' && $file ne '..') {
> if( -f "$dir/$file" && open(FILE,"< $dir/$file")) {
> $data=<FILE>;
> if($data =~ /\xf0\x0f\xc7\xc8/) {
> print "$dir/$file contains F0 0F C7 C8\n";
> }
> } elsif( -d "$dir/$file") {
> &findit("$dir/$file");
> }
> }
> }
> }
> $dir = shift || '/home';
>
> &findit($dir);
Basically, there's no protection from this. Adjust your execution of downline
loaded absolutes accordingly.
Steve Siegfried sos at skypoint.com sos1 at xtl.msc.edu
------------------------------
Date: Sat, 8 Nov 1997 12:06:42 -0500 (EST)
From: "Cary B. O'Brien" <cobrien at access.digex.net>
Subject: Recent Pentium opcode bug like Monoclonal Agriculture
[...] Once again I am reminded of the parallels between nearly complete
market domination by a hardware or software product, and the risks of
monoclonal agriculture (*).
In either case a flaw (be it a hardware error, software bug, or
susceptibility to a strain of bacteria or virus) has the potential to
cripple an entire industry, with serious sociological consequences. (cf.,
the Irish Potato Famine).
To me, at least, these parallels reinforce the importance of the
government's responsibility to prevent monopolistic activity on the
part of corporations. Loss of technological diversity is nearly as
bad as the loss of genetic diversity (although far easier to reverse).
Cary O'Brien
(*) By this I mean when a majority of the farms grow genetically
identical products.
------------------------------
Date: 1 Apr 1997 (LAST-MODIFIED)
From: RISKS-request at csl.sri.com
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 <risks-request at csl.sri.com> 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 risks at CSL.sri.com 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
------------------------------
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Cheers,
-- jra
--
Jay R. Ashworth High Technology Systems Consulting Ashworth
Designer Linux: Where Do You Want To Fly Today? & Associates
ka1fjx/4 Crack. It does a body good. +1 813 790 7592
jra at baylink.com http://rc5.distributed.net NIC: jra3
More information about the NANOG
mailing list