Forgot your password?
typodupeerror
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:
  • Heh... (Score:5, Funny)

    by pushing-robot (1037830) on Monday July 14, 2008 @04: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 @04:22PM (#24186561)

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

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

        by mweather (1089505) on Monday July 14, 2008 @04:41PM (#24186971)
        Sure, if you run the host computer with an AMD chip. But that would be silly.
        • Re: (Score:3, Insightful)

          by DaedalusHKX (660194)

          And then the irony will be that on Windows, the exploit will crash out, in Linux it will require a more up to date version of WINE to be installed so it can run and then crash like in Windows, and in BSD it simply won't run since BSD is that old "eunuchs" stuff that won't run Windows "cross platform" 'sploits.

          In the end, everyone is SAFE from attack by the sheer virtues of their software goodness that is inherent in "modern" OS's.

    • Re: (Score:3, Funny)

      by mjs_ud (849782)
      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: (Score:2, Funny)

        by Darkness404 (1287218)

        There aren't any potential problems with that solution are there?

        Except if you want them to arrive on time, have friendly support, sort through them getting lost in the mail and the rest of the joys that our government has imposed on us.

        • Re: (Score:3, Funny)

          by mweather (1089505)
          You haven't used UPS, FedEx or DHL recently, have you?
        • and the rest of the joys that our government has imposed on us.

          Like .42 USD postage? I highly doubt if anyone but the government ran our postal system we'd see anything but higher rates.

          • Re: (Score:3, Informative)

            by Arthur B. (806360)

            Really ?

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

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

            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.

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

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

      AMD?
    • Re: (Score:3, Funny)

      by Kamineko (851857)

      An Amiga? :)

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

      by at_slashdot (674436) on Monday July 14, 2008 @04: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: (Score:2, Funny)

        by cleatsupkeep (1132585)

        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.

        But on the flip side, they run AMD. :-).

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

        by g0bshiTe (596213) on Monday July 14, 2008 @04: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.
      • 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.

        Well I'm an AMD fan I'm sure feel protected against his code, on the other hand I guess you are not as afraid as me from having a CPU meltdown in case the fan over my heatsink stops working....=)

    • by Deadplant (212273)

      I'm safe because I run each new browser session using a disposable PC on the moon. (i use a telescope and wireless keyboards)

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

      by jimbolauski (882977) on Monday July 14, 2008 @04:43PM (#24187007) Journal
      My Chinese knockoff fentium processor will be safe.
  • by ergo98 (9391) on Monday July 14, 2008 @04:17PM (#24186477) Homepage Journal

    ...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 @04:18PM (#24186485)

    It's OK I run hurd.

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

    ...hack everywhere

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

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

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

      • 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.
      • Re:They may (Score:5, Insightful)

        by slimjim8094 (941042) <slashdot3@justconnected . n et> on Monday July 14, 2008 @04:34PM (#24186817)

        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: (Score:2, Funny)

          by hostyle (773991) *

          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.

          I guess they'll be calling it the Ron Burgundy exploit.

      • Re: (Score:3, Interesting)

        by arodland (127775)

        They also do volatile microcode loading IIRC, so you could deliver an OS "driver" that runs early at boot and closes the window... provided the flaw is within the realm of microcode patching anyway.

      • Re: (Score:3, Interesting)

        Microcode patches can't fix every type of CPU errata. In some cases a microcode patch might cripple the CPUs performance so badly as to make the fix impractical.
      • 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 [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.

    • Don't Intel processors contain a flash area? And, if so, what can it be used for? Can it be used in some way to fix or bypass this?

      • by trb (8509)

        Don't Intel processors contain a flash area? And, if so, what can it be used for? Can it be used in some way to fix or bypass this?

        If the processor has a flash area that can be used to patch processor bugs, I imagine that a crafty black hat could put bugs in there too.

    • by ymail.com (1311471) on Monday July 14, 2008 @04: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 @04: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 @04: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 0xygen (595606)

      There are a couple of JavaScript compilers which target the JVM, eg Mozilla's Rhino. It is quite a common way of compiling for a cross platform target.

  • by bill_mcgonigle (4333) * on Monday July 14, 2008 @04: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.

    • Exactly. There's absolutely no way that a processor could ever be made to be updated. It's not like those X86 instructions are implemented in code or anything. Hah. What would they call that, microcode or something? Completely stupid. :P

      • Does this mean we need to buy VIA and AMD? And maybe their STOCK???? How embarrassing for Intel. How maniacal for the rest of us that now need to patch most things we've bought in the past few years. Perhaps buying a G4 Mac was a good idea after all.....

  • by Thelasko (1196535) on Monday July 14, 2008 @04: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 corsec67 (627446)

      I think I have your cable right here [flickr.com].
      I hope your computer is all right.

    • Re: (Score:3, Funny)

      by ColdWetDog (752185) *

      *unplugs ethernet adapter*
      [NO CARRIER]

      Hate to break the news to you, but that "ethernet" cable you unplugged was a phone cord leading to a modem. And you thought you had broadband ...

      But you can't hear me now, can you?

    • Re: (Score:3, Funny)

      by db32 (862117)
      I'm currious what kind of ethernet adapter uses a carrier. I mean, modems do, because they MOdulate and DEModulate a signal with a [CARRIER] and with [NO CARRIER] the MO-DEM fails. Of course, it could be that you are safe from this exploit by using this new fangled ethernet adapter and don't need to unplug.
      • What is the link layer protocol on Ethernet? CSMA/CD

        Carrier Sense Multiple Access with Collision Detection.

  • by AlHunt (982887) on Monday July 14, 2008 @04: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 @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.
      • by AlHunt (982887) on Monday July 14, 2008 @04: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?

      • by rpozz (249652)

        If you take a look at some of the many exploits used on the internet, many of them have been created by copying-and-pasting proof of concept code distributed by security researchers. Given that anyone capable of creating a complex exploit like this would have to be pretty skilled, that completely excludes the average script kiddie.

        Although releasing proof of concept code may be necessary if Intel absolutely refuse to acknowledge or fix the issue, releasing it straight away for every single malware author to

    • Re: (Score:3, Insightful)

      by Todd Knarr (15451)

      As an end-user, to me it doesn't matter. If patches aren't available, I still need to know the details of the vulnerability so I can judge which of my systems need how much of their external access blocked or removed. To me, keeping it secret doesn't remove the vulnerability. I have to assume that, if it exists, the bad guys know about it and will use it. The only question for me is whether or not I know I need to take protective measures. If you say I don't need to, then I say "OK, let's you sign this cont

  • Quote (Score:4, Insightful)

    by kellyb9 (954229) on Monday July 14, 2008 @04: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 @04:32PM (#24186771)

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

  • by Jackie_Chan_Fan (730745) on Monday July 14, 2008 @04:32PM (#24186773)

    And slow windows to a crawl.

  • I wonder if these exploits can be prevented using a filter in the compiler?

  • by jd (1658) <imipak@yaCOLAhoo.com minus caffeine> 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.

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

  • you say tomato... (Score:5, Insightful)

    by DragonTHC (208439) <Dragon@NoSPAM.gamerslastwill.com> on Monday July 14, 2008 @04:38PM (#24186901) Homepage Journal

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

  • 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...
    • I doubt any such errata would encompass more than 10% of the PCs out there.

      Even if 0.1% of all PC's/servers where affected, that would have a huge impact. The problem with most of these errata is that they can't be patched by the OS.

  • 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 @05: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 @05: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.

    • Re: (Score:3, Interesting)

      by bluefoxlucid (723572)

      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.

      Remember that interpreting turns 1 instruction into hundreds of real machine instructions. I bare-minimum'd a basic add at around 112 or so once, based on a O(1) jump table and data decoding. That doesn't begin to touch on the data cache becoming, effectively, instruction cache for the interpreted instructions; or the massive overuse of instruction cache in an interpreter.

      "Virtual Machine" are more a toy than a real tool. Mono and Java and .NET require real, native system support (i.e. gtk+ for gtk# etc)

  • 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 @06: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.

COMPASS [for the CDC-6000 series] is the sort of assembler one expects from a corporation whose president codes in octal. -- J.N. Gray

Working...