Slashdot Mirror


Attacking Multicore CPUs

Ant writes "The Register reports that the world of current multi-core central processing units (CPUs) just entered is facing a serious threat. A security researcher at Cambridge disclosed a new class of vulnerabilities that takes advantage of concurrency to bypass security protections such as anti-virus software The attack is based on the assumption that the software that interacts with the kernel can be used without interference. The researcher, Robert Watson, showed that a carefully written exploit can attack in the window when this happens, and literally change the "words" that they are exchanging. Even if some of these dark aspects of concurrency were already known, Watson proved that real attacks can be developed, and showed that developers have to fix their code. Fast..."

16 of 167 comments (clear)

  1. Again? by DeHackEd · · Score: 5, Informative

    Looks like a variation (or maybe a dup) of this.

  2. Re:Fast? by Anonymous Coward · · Score: 5, Informative

    "No, such a difficult and obscure attack is not something that is priority one"

    Thread one sends a command to the OS and knowing that it will take time x to complete

    Thread two waits (x-d) before overwriting the buffer used to store the command (after the OS has checked it for validity, but before the OS has actually processed it)

    what's obscure about that?

  3. Neither submitter nor editor RTFA...? by perrin · · Score: 4, Informative

    It seems that neither the submitter nor the slashdot editor read the article in question. The attack is not specific to multi-core systems, and it works only against programs that wrap system calls to add additional system protection. So it does not pierce through standard OS security, and you already need to have execution privileges. The writeup is just hype and FUD, IMHO.

    1. Re:Neither submitter nor editor RTFA...? by Richard+W.M.+Jones · · Score: 3, Informative

      It's also old news.

      The SELinux guys debunked it over a month ago.

      Rich.

    2. Re:Neither submitter nor editor RTFA...? by Anonymous Coward · · Score: 3, Informative

      He didn't debunk it; he agreed that system call wrappers have all kind of problems and described Watson's work as a "good paper". He then pointed out that SELinux doesn't use system call wrappers, so it doesn't have these problems. That doesn't mean the problems aren't real elsewhere.

      But I agree it's old news. It was old news ten years ago. Security has to be in the kernel. Period.

  4. Re:Fast? by Anonymous Coward · · Score: 0, Informative

    VIRUSES

  5. Er, that's an OLD attack by davecb · · Score: 5, Informative

    It works on any multiprocessor, including an
    IBM 360/168 mainframe, where I first encountered it.

    --dave

    --
    davecb@spamcop.net
  6. Sidebar re Virii by davecb · · Score: 1, Informative

    Of course it's a word, it's a portmanteau word. A colleague and I made it up years ago, to see how many folks would thnk it was the proper latin tag for the little monsters.

    The proper latin plural for virus is, if memory serves, virus.

    --dave

    --
    davecb@spamcop.net
    1. Re:Sidebar re Virii by davecb · · Score: 2, Informative

      Of virus and the latin plural of a different
      declension (the plural of masculine and feminine
      words ending in -ius)

      --dave

      --
      davecb@spamcop.net
  7. Re:Fast? by ConceptJunkie · · Score: 2, Informative

    That would be true for "virii" only if the singular were "virius".

    --
    You are in a maze of twisty little passages, all alike.
  8. Parallelism by Peaker · · Score: 2, Informative

    This should probably even work in a single-processor setup, with ordinary threads, because the user-space system call wrapper is most probably pre-emptable (How would it prevent preemption?) and thus a thread-switch can occur during the syscall wrapper code. It may be less probable, but careful timing and multiple attempts can probably achieve this same exploit on an ordinary single-processor setup.

  9. Misleading article by Anonymous Coward · · Score: 2, Informative

    From the title it seemed clear to me this article was *supposed* to be about exploits unique to SMP hardware. Yet all it really is about is generic software race conditions totally unrelated to SMP and its concurrency model.

    For those of you who didn't read the article:

    "I was able to successfully bypass security in many system call wrappers by creating unmanaged concurrency between the attacking processes and the wrapper/kernel. This was possible on both uniprocessor systems and multiprocessor systems."

    I wish people posting articles would stop with all the bullshit. Its really starting to get old.

  10. Re:Fast? by Sique · · Score: 3, Informative

    Main problem: the latin virus, meaning 'slime' or 'poison', is a singularitantum. So there is no historical plural for virus. That allows us to just make one up. And we should make it so, that it doesn't interfere with the plural of vir (man).

    --
    .sig: Sique *sigh*
  11. Re:So what? by Anonymous Coward · · Score: 1, Informative

    Which is also why bananas almost became extinct. There just wasn't enough diversity in the gene pool. One virus could infect bananas from like all over the world.

    Now they're all genetically modified.

  12. Re:Fast? by Tim+C · · Score: 3, Informative

    Correct me if I'm wrong, but that sounds awfully similar to a race condition (it clearly isn't one, but it certainly *looks* like one), which would seem to me to mean that it would have all the same dependencies on the vagaries of system load. I'm not saying that this would be impossible to pull off, just difficult to do so consistently.

    Of course, depending on what you're actually trying to achieve, consistency may not be an issue.

  13. Re:Fast? by JoelKatz · · Score: 3, Informative

    This has nothing to do with multi-core CPUs. This exact same attack would work on the run-of-the-mill SMP systems that have been around for decades. Multi-core CPUs just make SMP systems more common.