Slashdot Mirror


Kaspersky To Demo Attack Code For Intel Chips

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."

20 of 303 comments (clear)

  1. They may by Sycraft-fu · · Score: 5, Informative

    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.

    1. Re:They may by Gazzonyx · · Score: 4, Informative

      Yeah, most Linux distros have a microcode update service, although it has to be enabled in the kernel at compilation time, IIRC.

      --

      If I mod you up, it doesn't necessarily mean I agree with what you've said, sorry.

    2. Re:They may by AcidPenguin9873 · · Score: 4, Informative

      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.

  2. Re:Java or Javascript? by MindStalker · · Score: 4, Informative

    The official conference website says the same thing
    http://conference.hackinthebox.org/hitbsecconf2008kl/?page_id=214

    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

  3. It must depend some on the OS by jd · · Score: 5, Informative
    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.

    --
    It's a small world and it smells funny; I'd buy another if it wasn't for the money; Take back what I paid (SoM)
    1. Re:It must depend some on the OS by the_brobdingnagian · · Score: 5, Informative
      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.

    2. Re:It must depend some on the OS by grcumb · · Score: 3, Informative

      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.

      --
      Crumb's Corollary: Never bring a knife to a bun fight.
  4. Re:Speculative by Anonymous Coward · · Score: 4, Informative

    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

  5. Re:Publicly available? by pclminion · · Score: 3, Informative

    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.

  6. Re:Quote by krgallagher · · Score: 2, Informative

    What about a Sun workstation?

    --

    Insert Generic Sig Here:

  7. This exploit is extremely limited in scope... by BUL2294 · · Score: 2, Informative

    ...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...

    --
    Windows 3.1x calc: 3.11 - 3.10 = 0.00
  8. Re:Speculative by cnettel · · Score: 2, Informative

    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.

  9. i've read a number of story summaries in my time by circletimessquare · · Score: 3, Informative

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

    --
    intellectual property law is philosophically incoherent. it is your moral duty to ignore it or sabotage it
  10. Re:Java or Javascript? by Anonymous Coward · · Score: 1, Informative

    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).

  11. Re:Im sure his Anti Virus will stop it :) by Clandestine_Blaze · · Score: 4, Informative

    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:
    http://xkcd.com/250/

  12. Re:Heh... by holloway · · Score: 2, Informative

    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.

  13. Re:That's Nothing, This November I'm Going To... by Anonymous Coward · · Score: 5, Informative

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

  14. Re:That's Nothing, This November I'm Going To... by TheRaven64 · · Score: 4, Informative

    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.

    --
    I am TheRaven on Soylent News
  15. Re:Heh... by Arthur+B. · · Score: 2, Informative

    Really ?

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

    http://www.lysanderspooner.org/STAMP2.htm
    http://www.lysanderspooner.org/STAMP1.htm
    http://www.lysanderspooner.org/STAMP3.htm

    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.

    --
    \u262D = \u5350
  16. Re:Are you really sure about that? by brusk · · Score: 2, Informative

    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.

    --
    .sig withheld by request