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

Comments

Again?

[DeHackEd]

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

Re:Fast?

[Anonymous Coward]

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

Neither submitter nor editor RTFA...?

[perrin]

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.

Re:Neither submitter nor editor RTFA...?

[Richard W.M. Jones]

It's also old news.

The SELinux guys debunked it over a month ago.

Rich.

Re:Neither submitter nor editor RTFA...?

[Anonymous Coward]

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.

Er, that's an OLD attack

[davecb]

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

--dave

Re:Fast?

[Sique]

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

Re:Fast?

[Tim C]

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.

Re:Fast?

[JoelKatz]

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.