1997-11-09 - Sloppy Chips from Intel

Header Data

From: Eric Cordian <emc@wire.insync.net>
To: cypherpunks@cyberpass.net
Message Hash: 9e2ac682d8fa44f2e7b6030919ae7809976240ec00847190a850976f9e7fabc3
Message ID: <199711090056.SAA17235@wire.insync.net>
Reply To: N/A
UTC Datetime: 1997-11-09 01:10:56 UTC
Raw Date: Sun, 9 Nov 1997 09:10:56 +0800

Raw message

From: Eric Cordian <emc@wire.insync.net>
Date: Sun, 9 Nov 1997 09:10:56 +0800
To: cypherpunks@cyberpass.net
Subject: Sloppy Chips from Intel
Message-ID: <199711090056.SAA17235@wire.insync.net>
MIME-Version: 1.0
Content-Type: text/plain



By now everyone has probably heard that Intel Pentium and Pentium MMX
chips hang when executing the instruction sequence F00FC7C8 even when
in an outer ring of privilege or in V86 mode.
 
With numerous small Linux-based ISPs out there, often providing shell
services to anonymous customers, or serving customer-provided CGI
programs, the existence and public disclosure such an easily
exploitable flaw in their CPU's hardware protection mechanism is
catastrophic.
 
Intel, rather than extensively verifying their microprocessors before
shipping them out the door, now advertises that its chips may contain
"errata," or "deviations from published specifications" and doesn't
seem to regard such problems as any big deal.
 
This latest flaw is the third unexpected surprise in Intel's Pentium
product line.  A serious precision problem in double precision
floating divide was discovered in early Pentium chips, and it was
recently disclosed that there are circumstances under which the
Pentium Pro may fail to generate an exception when a Float to Integer
conversion overflows.
 
While today's problem does not permit clandestine entry into a system,
since it kills the system when it is exercised, it does raise the
question of whether there are other more subtle problems in the
hardware protection mechanism, which might enable knowlegable users to
execute an occasional instruction at the wrong privelege level, or
otherwise do things which should be prohibited according to the
published hardware specifications.
 
It is interesting to note that such problems have not been reported in
compatible chips manufactured by AMD, a competitor of Intel.
 
Buggy microprocessor microcode can produce very subtle exploitable
faults in a chip, which are almost impossible to notice when running
ordinary applications and operating systems.  Instructions may do the
wrong thing only when they follow certain other instructions.  There
may be rare times when the processor is wrongly interruptable, or when
a restricted instruction is not forbidden, or is given access at the
wrong privilege level, or with incorrect address translation.
 
Were such features to be deliberately introduced into a chip, in order
to permit a backdoor for undetected entry, they could be made
completely undetectable, and could depend upon any number of unlikely
conditions, or even specific hidden register values, in order to be
made manifest.  Every microprocessor could even have its own "key" for
the activation of such "special features."
 
Unlike Unix, for which complete compilable source code is available,
we know little about what what microcode is run through the several
million transistors on a typical microprocessor. If sloppy engineering
alone produces such dangerous faults, imagine what could happen should
industry decide to deliberately cooperate with various LEAs and TLAs.
(In the national interest, of course.)
 
The possiblities are truly mind-boggling.  Perhaps exploits like tapping
Aldrich Ames' PC and crashing Saddam Husseins' PCs en masse were not done
by black bag jobs and viri, but by the activation of "National Security"
backdoors present in all complex modern microprocessors.

--
Eric Michael Cordian 0+
O:.T:.O:. Mathematical Munitions Division
"Do What Thou Wilt Shall Be The Whole Of The Law"

 






Thread