Stories
Slash Boxes
Comments

News for nerds, stuff that matters

Slashdot Log In

Log In

Create Account  |  Retrieve Password

Kaspersky To Demo Attack Code For Intel Chips

Posted by ScuttleMonkey on Mon Jul 14, 2008 03:14 PM
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."
+ -
story

Related Stories

This discussion has been archived. No new comments can be posted.
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
 Full
 Abbreviated
 Hidden
More
Loading... please wait.
  • Heh... (Score:5, Funny)

    by pushing-robot (1037830) on Monday July 14 2008, @03:15PM (#24186435)

    At least I know I'm safe because I run... Oh, crap.

    • Re:Heh... (Score:5, Interesting)

      by hostyle (773991) * on Monday July 14 2008, @03:22PM (#24186561)

      I wonder if running inside a VM could at all mitigate the attack.

    • Time to pull the ethernet cable out. Would someone like to send me the slashdot articles via USPS? There aren't any potential problems with that solution are there? Wait...please send anthrax free too.
                • Re:Reality check (Score:5, Insightful)

                  by jonbryce (703250) on Monday July 14 2008, @04:35PM (#24187867) Homepage

                  You might think that would happen, but if the British experience of removing the monopoly is anything to go by, your postal service will get worse.

                  We've always had overnight delivery, but then, Britain is a much smaller country.

                  The private operators are only interested in business mail. DX will do deliveries for small companies. The rest of them are only interested in bulk mail, such as bank statements and utility bills. For the rest of us, Royal Mail are now charging more, because they get less of the bulk mail to subsidise personal mail, and they are becoming much less reliable at delivering it.

                • Re:Reality check (Score:5, Insightful)

                  by Paradise Pete (33184) <listcatcher@fastm a i l.fm> on Monday July 14 2008, @04:40PM (#24187925) Journal
                  Do you really think UPS couldn't eat the postal service's lunch on 1st Class postage if they were allowed to compete?

                  .

                  I don't know. To me it's pretty darn amazing that for 42 cents I can drop an envelop in a slot and a few days later it is hand-delivered to someone on the other side of the country. If that service didn't exist and you asked me to guess what it would cost, 42 cents would not be the answer.

                • Re:Reality check (Score:5, Insightful)

                  by mOdQuArK! (87332) on Monday July 14 2008, @05:47PM (#24188753)

                  Actually, the main "valid" reason for the government providing letter service is to provide services to those geographic areas where the "free market" would flat out decide that it wasn't worth servicing those areas. If this wasn't a requirement of the USPS, they could easily drop all their rural routes & compete with any of the normal package carriers.

                  Of course, whether or not we should be inefficiently supporting those remote rural areas is a whole 'nother area of debate. I'm sure there's a lot of small town supporters that would scream bloody murder if you argue that those small towns should be allowed to disappear by cutting off any form of government infrastructure subsidy for those locations.

    • Re:Heh... (Score:5, Funny)

      by phorm (591458) on Monday July 14 2008, @03:27PM (#24186661) Homepage Journal
      At least I know I'm safe because I run...

      AMD?
    • Re:Heh... (Score:5, Interesting)

      by at_slashdot (674436) on Monday July 14 2008, @03:31PM (#24186741)

      At least I know I'm safe because I run... Oh, crap.

      I'm sure AMD fans will make a point that they are protected in this case.

      • Re:Heh... (Score:5, Insightful)

        by g0bshiTe (596213) on Monday July 14 2008, @03:53PM (#24187191)
        Possibly, but as an AMD user myself I can't help but wonder if what can be done on Intel with this won't also open Pandora's box on AMD using the same or similar methods.
    • Re:Heh... (Score:5, Funny)

      by jimbolauski (882977) on Monday July 14 2008, @03:43PM (#24187007) Journal
      My Chinese knockoff fentium processor will be safe.
  • ...demonstrate how you can make a 1GW fusion reactor out of nothing but a sweaty gym sock and the corpse of a field mouse.

    No, seriously. 100%. Cross my heart.

  • by y86 (111726) on Monday July 14 2008, @03:18PM (#24186485)

    It's OK I run hurd.

  • by Anonymous Coward on Monday July 14 2008, @03:20PM (#24186523)

    ...hack everywhere

  • by Zenaku (821866) on Monday July 14 2008, @03:22PM (#24186557)

    I'm sure Intel will release a patch. ;)

    • They may (Score:5, Informative)

      by Sycraft-fu (314770) on Monday July 14 2008, @03: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.

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

        by Gazzonyx (982402) on Monday July 14 2008, @03:33PM (#24186805)
        Yeah, most Linux distros have a microcode update service, although it has to be enabled in the kernel at compilation time, IIRC.
      • Re:They may (Score:5, Insightful)

        by slimjim8094 (941042) <slashdot@justconnected.net> on Monday July 14 2008, @03:34PM (#24186817) Homepage

        If this can consistently crash my computer regardless of OS or browser, I'd sure as hell update my BIOS.

        This is a big deal.

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

        by AcidPenguin9873 (911493) on Monday July 14 2008, @04: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 [wikipedia.org] 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 [wikipedia.org] 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 ymail.com (1311471) on Monday July 14 2008, @03:36PM (#24186855)
      If Intel doesn't release that hardware patch, it's time to go play in another Sandbox.

      Or else go back to 1999 where Pentium III machines with Intel's processor ID enabled in CMOS enable shoppers to have an "enhanced online experience" while they run IE 4.01 from Windows machines that aren't behind a firewall ... to safely prove who they are to websites.
  • by Yvan256 (722131) on Monday July 14 2008, @03:23PM (#24186577) Homepage Journal

    ... remotely attack a computer using JavaScript or TCP/IP packets ... can be exploited using certain instruction sequences and a knowledge of how Java compilers work

    So is it Java or Javascript? Either the summary is wrong or this guy doesn't even know the difference between the two.

  • Huh? (Score:4, Insightful)

    by antifoidulus (807088) on Monday July 14 2008, @03:23PM (#24186583) Homepage Journal
    will show how processor bugs can be exploited using certain instruction sequences and a knowledge of how Java compilers work

    Huh? Javascript != Java!!!!
  • by bill_mcgonigle (4333) * on Monday July 14 2008, @03:24PM (#24186593) Homepage Journal

    a knowledge of how Java compilers work

    Hrm, seems like he's counting on things happening in a certain sequence. So, perhaps a JVM could do more stuff in an unpredictable order? Perhaps using an SSA representation and context switching threads? Yeah, slightly more expensive, but let Firefox turn it on for me when I'm running untrusted code.

  • by Thelasko (1196535) on Monday July 14 2008, @03:25PM (#24186631) Journal
    no amount of tinfoil can protect me from this exploit. Only one thing left to do...

    *unplugs ethernet adapter*
    [NO CARRIER]
  • by AlHunt (982887) on Monday July 14 2008, @03:26PM (#24186637) Homepage Journal

    "I'm going to show real working code...and make it publicly available," Kaspersky said,

    Indeed. And are you going to make patches publicly available for all the hardware and operating systems in the world, too?

    • by pclminion (145572) on Monday July 14 2008, @03: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.
      • by AlHunt (982887) on Monday July 14 2008, @03:49PM (#24187097) Homepage Journal

        >I see, so your argument is that if it can't be fixed by the discoverer,
        > they should keep it obscure.

        Yeah, we could have the oft-heard chicken or egg debate. But we both know where it would end up. One side would say "disclose everything right away" and the other side would say "give the vendors a chance to fix it first". See how much time we just saved?

  • Quote (Score:4, Insightful)

    by kellyb9 (954229) on Monday July 14 2008, @03:32PM (#24186767)

    ... Windows XP, Vista, Windows Server 2003, Windows Server 2008, Linux, and BSD. An attack against a Mac is also a possibility.

    Why don't they just say... "any computer that has an Intel chip?".. shock value I guess.

  • Which ones? (Score:5, Interesting)

    by Taibhsear (1286214) on Monday July 14 2008, @03:32PM (#24186771)

    Do we have a list of the processors affected by this? Or is this issue in ALL Intel processors?

  • by jd (1658) <imipakNO@SPAMyahoo.com> on Monday July 14 2008, @03: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.

    • by the_brobdingnagian (917699) on Monday July 14 2008, @03:49PM (#24187095) Homepage
      Now that you mention OpenBSD, I recall an email from Theo de Raadt (2007-06-27 17:08:16 - source [marc.info]):

      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.

  • They call it a flaw, while I call it a backdoor.

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

  • by Mathness (145187) on Monday July 14 2008, @04:08PM (#24187385) Homepage

    As seen on today's TV schedule for Discovery

    Now showing: Intel, when code attacks.
    Next show: Lasers.
    Next week: Shark week.

  • Interesting (Score:4, Insightful)

    by mlwmohawk (801821) on Monday July 14 2008, @04:11PM (#24187463)

    If the fundamental flaw is BOTH the way intel chips execute code and a primitive in Java, that could be dangerous.

    I could get all snarky and tell everyone I buy AMD, but I wouldn't be too confident that a similar exploit couldn't exist there either.

    This is all possible if...

    You need to reliably produce a series of instructions on a typical jvm. This doesn't present a problem as primitive expressions probably get predictable JIT sequences,

    The next question is what kind of exploit? Are you running native x86 code? If so, you are still limited by the OS level protection. If you can then create an exploit that elevates your permissions that doubly bad.

    One more snarky comment. I don't like JITs. I like my interpreted code interpreted, and I like my binary code native. I prefer something like a PHP model where you put glue in PHP and hard code in a C extension or a service.

  • If malware based on this "attack code" got into the wild, it sounds like one of the attack vectors would be malicious Web sites (which is nothing new). As many security researchers have been recommending for years, turning off JavaScript and other active content by default will greatly reduce the potential for infection, even from many kinds of as-yet undiscovered exploits. A good way to do this with Firefox (without ruining compatibility with trustworthy sites) is to install NoScript [noscript.net], which allows you to whitelist trusted sites while allowing you to block scripts, Java, Flash, Silverlight, other plug-ins, etc. on every other site by default.

    Of course, if the flaw lies in the microprocessor, then there are certainly other potential attack vectors than just malicious Web sites.

    Someone pointed out that Intel processors are BIOS-upgradeable. What about computers based on EFI [wikipedia.org] instead of BIOS, such as all the Intel-based Macs?

    Also, as someone else pointed out, the headline is extremely misleading. The security researcher Kris Kaspersky is not affiliated with Kaspersky Lab [kaspersky.com] or Eugene Kaspersky [wikipedia.org], but he's apparently the author of a number of books [amazon.com] on programming and other computer subjects.

  • This is so old! (Score:5, Interesting)

    by IT Hippy (895149) on Monday July 14 2008, @05:29PM (#24188553)
    Back in the 1970's you could really screw up the early CDC machines with the following written in FORTRAN:-

    1 GOTO 1

    The compiler would write in machine code:-

    BR .

    When you executed this the CPU would instack the instruction and the machine would crash. It could get worse as the memory was mainly core and the mainframe would just try to restart the program it was executing. So often you had to wait for the CDC Engineer to arrive to pull the correct wires off the CPU to allow the machine to restart.

    In fact in those days they fixed it in the FORTRAN compiler to turn the BRANCH into a JUMP that voided the instack and allowed the hardware to get control back from the CPU.

    Is this really History repeating itself.

    • Re:Speculative (Score:4, Informative)

      by Anonymous Coward on Monday July 14 2008, @03: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