F00F bug or why morons shouldn’t be writing about security (again)

kao

Every once in a while, I read an article about security which is so incredibly bad that I just have to comment on it.

This time, it's an article from iTWire called "When F00F bug hit 20 years ago, Intel reacted the same way". It's written by Sam Varghese who claims to have decades of experience in the field. Let's see..

Make Intel CPU to hang remotely and anonymously?

Let me write that down!

Any Intel Pentium/Pentium MMX could be remotely and anonymously caused to hang, merely by sending it the byte sequence "F0 0F C7 C8".

This statement is incorrect in so many ways!

Yes, there was a bug in Pentium CPUs. CPU would freeze when executing instruction lock cmpxchg8b eax which has the opcode "F0 0F C7 C8". Can you see the difference?

  1. CPU doesn't hang on merely seeing the data sequence "F0 0F C7 C8". It hangs when trying to execute these bytes. Big difference! And if someone is able to run arbitrary instructions on your CPU, you have much bigger problems than just a simple hang.
  2. There is no f*ing way to run any code on any CPU remotely and anonymously. You can remotely exploit a bug in firmware/OS/software to execute some code - that's called remote code execution. But that is not specific to Intel CPUs and have nothing to do with the F00F bug in particular.

Dear Sam Varghese, please stop writing about security. Open a hotdog stand or do anything else that doesn't involve computers. You just don't get them.

4 thoughts on “F00F bug or why morons shouldn’t be writing about security (again)

  1. Your wrong, Dos, Linux and Windows allowed this to happen in user land without root access. Remote execution was also possible because back then. CGI scripts were used, and they were exploited to run code all the time. So I have no idea what your going on about. Either you werent in the field 20 years ago or you have no idea how OS's worked in 1997. We didn't have virtual sandboxes or even proper memory protection. It was pretty much the wild west.

    As for just having the f00f sequence in memory, no it has to be executed.

    1. Yes, operating systems were much easier to exploit 20 years ago. And that's pretty much what I wrote:

      You can remotely exploit a bug in firmware/OS/software to execute some code - that's called remote code execution.

      But you can't just magically "remotely and anonymously" send a "byte sequence" directly to a CPU. 🙂

  2. I enjoy reading articles, opinions, responses on technical stuff to invigorate the mind, the same way reading advances in nuclear fusion, cancer research etc. That's a good way in keeping away degenerative diseases like dementia etc. Sam Varghese is an accomplished tech journalist. Tech journalists break tech news in a manner unlike tech journals like Scientific American. It has to be read most times in between the lines. His writing on the Intel bug can be simply understood on key words like an AI construct: Intel CPU bug, can be introduced by anyone, can freeze Intel CPU which in turn leads to catastrophic events. Reading between the lines it has to assume the bytes have to be executed .. all in machine codes all in binary, otherwise the statements came from a moron which obviously he is not.
    On these points I have to agree. In embedded systems many programs are written in assembly. A code can be easily written to freeze a CPU, like 0x76 in Z80, 0xF4 in Intel-x86, 0x0b00 in ARMv7.. etc. after executing the code which can wait for an interrupt where the vector can be changed to point to anywhere. Remotely a coder can send a binary block to an applet that auto-executes into the freeze code.
    I designed my own 32-bit FPGA CPU that traps unexecutable codes to an auto-reset. There is no way any code could freeze my CPU. Only a moron would design a CPU used by billions on the planet to freeze on one wrong code. In this Intel bug case among many other bugs, the moron is Intel not Sam Varghese. Remember Intel's moronic self-made road to disrepute which lead to this road towards ruin.. the 486-DX/486-SX deception, the i432 fiasco, i80860 fail, failure to switch x86 to i960, itanium fiasco, Intel Atom on smartphone fiasco, RISC-V dilly-dally ditching after some 6 months on the Pathway project, among others. Fast forward 2025.. talks of merger with AMD.. Jensen Huang talks on acquiring Intel via NVIDIA, now new CEO without a clue how to save Intel. Intel has been running on faulty architecture for so long its incredible how the world was deluded into using the old 8/16-bit legacy 1970's architecture with quirky multi-byte instructions, now 3000+ set of instructions, unorthogonal registers with accumulator-based dedicated mindset. Now it has finally met End-Of-Life state of an unsurmountable brick wall to the x86 platform.
    I'm now using RISC-V on Linux Debian powered by an Android phone charger all made in China. The only non-Chinese are anything from Linux, RISC-V all freeware easily downloadable. I would say the greatest contribution to computing is Linus Torvalds, David Patterson together with their freeware philosophy and streamlining platforms. x86 has got to go together with Windows. Linux-RISC5 is the next-gen computing. Intel's new CEO is still fumbling after taking its reins and will jump ship in due time.

Leave a Reply

  • Be nice to me and everyone else.
  • If you are reporting a problem in my tool, please upload the file which causes the problem.
    I can`t help you without seeing the file.
  • Links in comments are visible only to me. Other visitors cannot see them.

 −  5  =  2