Forgot your password?
Security IT

Kaspersky To Demo Attack Code For Intel Chips 303

Posted by ScuttleMonkey
from the also-releasing-a-paint-by-number dept.
snydeq writes "Kris Kaspersky will demonstrate how attackers can target flaws in Intel microprocessors to remotely attack a computer using JavaScript or TCP/IP packets, regardless of OS. The demo will be presented at the Hack In The Box Security Conference in Kuala Lumpur in October and will show how processor bugs can be exploited using certain instruction sequences and a knowledge of how Java compilers work, allowing an attacker to take control of the compiler. The demonstrated attack will be made against fully patched computers running a range of OSes, including Windows XP, Vista, Windows Server 2003, Windows Server 2008, Linux, and BSD. An attack against a Mac is also a possibility."
This discussion has been archived. No new comments can be posted.

Kaspersky To Demo Attack Code For Intel Chips

Comments Filter:
  • They may (Score:5, Informative)

    by Sycraft-fu (314770) on Monday July 14, 2008 @04:24PM (#24186611)

    Their new processors can have their microcode updated, and indeed they do update it with BIOS updates. Dunno if people would bother to update their BIOS to patch it, but yes Intel processors can be patched in the field.

  • by MindStalker (22827) <mindstalker&gmail,com> on Monday July 14, 2008 @04:31PM (#24186757) Journal

    The official conference website says the same thing []

    Reading the conference website sounds like he is saying the can crash computers through forced tight loops via multiple languages, javascript, java, even TCP/IP

  • Re:They may (Score:5, Informative)

    by Gazzonyx (982402) on Monday July 14, 2008 @04:33PM (#24186805)
    Yeah, most Linux distros have a microcode update service, although it has to be enabled in the kernel at compilation time, IIRC.
  • by jd (1658) <imipak&yahoo,com> on Monday July 14, 2008 @04:34PM (#24186809) Homepage Journal
    For starters, OS' running on either virtual or simulated processors rather than physical ones won't necessarily use the physical instructions that have the vulnerabilities, no matter what the physical processor that the OS is technically using. (If I run Linux under ArcEm, and run ArcEm on an Intel processor, unless ArcEm itself uses the broken instructions, I cannot see how an attacker can reach the Intel processor from the Linux environment for the attack to take place. This is important because the composite environment is nothing more than a really heavy, multi-layer OS as far as the applications are concerned, and this attack is supposedly independent of OS.)

    If it's via Java, then it must also depend some on the implementation. I doubt that IBM's java engine uses the same calls to the processor as Sun's, which means that there is further abstraction that the claim has to somehow deal with.

    Now, on the opposite side of the argument, there's the issue of what happens if the claim is justified. If this is a remote exploit that is truly OS-independent, then it is a remote exploit that can hit OpenBSD, Trusted Solaris, and other secure OS'. These are OS' used for commercially-sensitive work and classified work. If they are potentially vulnerable to attack, that could seriously impact a lot of organizations that, well, really aren't going to like it. In the event of a conflict flaring up between Intel and the US Marines, we may see them moving the bombing practice areas for their aircraft into the North American mainland after all.

  • Re:Speculative (Score:4, Informative)

    by Anonymous Coward on Monday July 14, 2008 @04:34PM (#24186811)

    An attack against a Mac is also a possibility

    That's a bit of a conjecture isn't it? Can we at least have a demonstration?

    OMFG! From the summary:

    Attack Code For Intel Chips ... regardless of OS

  • by pclminion (145572) on Monday July 14, 2008 @04:42PM (#24186989)
    I see, so your argument is that if it can't be fixed by the discoverer, they should keep it obscure. That way, there is no incentive for the vendor to solve the problem since they don't even know about it. Thus, leaving the door open for other nasty people to discover it and exploit it with nobody aware it is even possible. Good plan you got there.
  • Re:Quote (Score:3, Informative)

    by krgallagher (743575) on Monday July 14, 2008 @04:46PM (#24187039) Homepage
    What about a Sun workstation []?
  • by the_brobdingnagian (917699) on Monday July 14, 2008 @04:49PM (#24187095) Homepage
    Now that you mention OpenBSD, I recall an email from Theo de Raadt (2007-06-27 17:08:16 - source []):

    Note that some errata like AI65, AI79, AI43, AI39, AI90, AI99 scare the hell out of us. Some of these are things that cannot be fixed in running code, and some are things that every operating system will do until about mid-2008, because that is how the MMU has always been managed on all generations of Intel/AMD/whoeverelse hardware. Now Intel is telling people to manage the MMU's TLB flushes in a new and different way. Yet even if we do so, some of the errata listed are unaffected by doing so.
    As I said before, hiding in this list are 20-30 bugs that cannot be worked around by operating systems, and will be potentially exploitable. I would bet a lot of money that at least 2-3 of them are.

    And from TFA:

    "It's possible to fix most of the bugs, and Intel provides workarounds to the major BIOS vendors," Kaspersky said, referring to the code that controls the most basic functions of a PC. "However, not every vendor uses it and some bugs have no workarounds."

    Sounds like the the same issues to me.

  • by BUL2294 (1081735) on Monday July 14, 2008 @04:49PM (#24187117)
    ...unless there is CPU errata that Intel hasn't fixed for years. We've got the chicken-little "the sky is falling" reaction going on here but (unless I'm seriously misguided) Intel fixes their errata.

    My personal view is that such malware may only be able to take over a very small percentage of systems out there. The scope may be limited to something as (relatively) rare as an Intel Core 2 CPU within a specific FSB range and specific stepping. Throwing all those factors together, I doubt any such errata would encompass more than 10% of the PCs out there. Considering how many different variations of CPUs are out there--Intel/AMD/Via, Pentium-D/Core 2/Xeon/Pentium-M/Pentium 4, FSB differences, stepping, etc.; such malware might be extremely dangerous for a very small subset of Internet-connected PCs.

    Now, if a malware author knows of a CPU bug that Intel/AMD does not know about, then this could be extremely serious, encompassing multiple generations of CPUs...
  • Re:Speculative (Score:3, Informative)

    by cnettel (836611) on Monday July 14, 2008 @04:56PM (#24187235)

    Nope. But I'm saying every OS use the chip differently. For example, Windows apps share the same memory space (well, far pointers do anyhow). So this does affect what a CPU-level attack could do. That and other issues I'm sure.

    Win 3.1 called and wants it memory model(s) back. Win32 has a 32-bit flat memory space (or 64-bit on x64), all pointers are the same size, segments do not matter and each process has a local space. Some pages might be shared, of course, but that's done through memory mapping, like in (mostly) any other OS. WinCE has/had some interesting slots, though.

  • and this one ranks among the hallowed few best described as "excuse me, i just crapped my pants"

  • by Anonymous Coward on Monday July 14, 2008 @05:06PM (#24187363)

    Shrug. Mozilla Rhino [] is javascript implemented in java. It's handy if you want to embed a friendly interpreter in your java app, sort of like the way TCL used to be used for C apps, and the way GNU intended Guile to be used (but screwed up because apparently 90% of everyone hates Scheme).

    Some java people prefer beanshell or jruby, but I like rhino because, well, it's standard javascript instead of completely made up (beanshell) or obnoxiously line-noisy (ruby).

  • by Clandestine_Blaze (1019274) on Monday July 14, 2008 @05:23PM (#24187657) Journal

    Im sure his Anti Virus will stop it :)

    I initially made that mistake too, but Kris Kaspersky != Eugene Kaspersky

    Kris [] is a security researcher and author.
    Eugene [] is the guy behind Kaspersky Lab [].

    I wish the article had made the distinction, since some people are more familiar with Kaspersky the anti-virus creator and not the author.

    Though this does remind me of the urban legend that anti-virus companies are behind all of the anti-viruses: []

  • Re:Heh... (Score:3, Informative)

    by holloway (46404) on Monday July 14, 2008 @05:26PM (#24187705) Homepage

    Wireless keyboard eh? []

    You should do it like Missle Command and ignite the atmosphere with explosions that can be OCRed from your moon computer's webcam.

  • Re:They may (Score:5, Informative)

    by AcidPenguin9873 (911493) on Monday July 14, 2008 @05:27PM (#24187719)

    Only some things can be fixed via a ucode patch, others cannot. See AMD's TLB errata for an example of something that cannot. Other things can be fixed by disabling a feature, but disabling that feature might cost performance. Once again, see AMD's TLB errata for an example. Still other things can be worked around in the OS, sometimes for negligible performance loss, sometimes not. The Intel F00F bug [] was a perfect example of something that could be worked around in the OS with no performance loss, and the AMD TLB errata had an OS workaround too which incurred a small (1%?) performance loss. Other things have almost no workaround, and require Intel or AMD to recall silicon and give out new processors. Intel's Pentium FDIV bug [] was a good example of that. It depends entirely on what piece of the chip is at fault.

    If something can be fixed in ucode for a negligible performance loss, or worked around in the OS for a negligible performance loss, that's the best-case scenario for Intel. In that case it's just a matter of getting BIOSes/OSes updated and patches rolled out to OEMs.

  • by Anonymous Coward on Monday July 14, 2008 @05:29PM (#24187763)

    Err, Kris Kaspersky has a good reputation and does write pretty good books [].

  • by grcumb (781340) on Monday July 14, 2008 @06:00PM (#24188207) Homepage Journal

    Now that you mention OpenBSD, I recall an email from Theo de Raadt (2007-06-27 17:08:16 - source []):

    As I said before, hiding in this list are 20-30 bugs that cannot be worked around by operating systems, and will be potentially exploitable. I would bet a lot of money that at least 2-3 of them are.

    People have been aware that microprocessor bugs are potentially quite dangerous for some time now. Here's a write-up of Adi Shamir's report to RISKS about using processing bugs to steal private encryption keys [].

  • by TheRaven64 (641858) on Monday July 14, 2008 @06:53PM (#24188809) Journal
    The Core and Core 2 both have serious errata relating to how they handle virtual memory. It is possible to violate page and segment protections using these, although it is not obvious how to do so in a way that does anything other than crashing (i.e. there is a quite difficult possible DoS and may be a very difficult arbitrary privileged code execution hole). This requires running arbitrary (unprivileged) code, but apparently he's found a way of generating the required code in a JVM.
  • Re:Heh... (Score:3, Informative)

    by Arthur B. (806360) on Monday July 14, 2008 @07:32PM (#24189233)

    Really ?

    You don't know about the American Letter Company then. [] [] []

    The sad truth is, USPS is a coercive monopoly which wouldn't exist if it where not for competitors being threatened of jail and large fines.

  • by brusk (135896) on Monday July 14, 2008 @10:00PM (#24190585)

    Can you actually point to the section of the US code that prohibits a third party from delivering first class style mail? I mean, if a private company wanted to sell a service moving an ounce across 3000 miles for 50 cents, they could.

    From Wikipedia []:

    18 U.S.C. 1693â"1696 and 39 U.S.C. 601â"606, implemented under 39 Code of Federal Regulations Parts 310 and 320.

    The federal government has strong powers in this regard because there's a postal clause in the Constitution.

We have a equal opportunity Calculus class -- it's fully integrated.