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

Fast?

[JordanL]

and showed that developers have to fix their code. Fast...

Ummm... no. In a world where the list of things that most developers need to fix is quite lengthy, some of which renders your average app unusable or even dangerous, fixing an exploit of a hardware configuration which has no proven virii in the wild is not at the top of the list.

Yes, it's important to be proactive. No, such a difficult and obscure attack is not something that is priority one.

Re:Fast?

[g0dsp33d]

I agree. If you read the article, you'll notice that such attacks as "This was possible on both uniprocessor systems and multiprocessor systems." Also, it has been known since at least 1998. I'm guessing its not that big of a deal, because exploit code would be difficult, there are easier targets, and lastly because anti-virus software could probably still look for the code(not in real time, but only when its infected on disk or transit).

The example they give is wrong

[A beautiful mind]

to bypass security protections such as anti-virus software

Anti-virus software isn't by any means "security protection", especially the type that works on a heuristical basis. They are simply long lists of known to be disadvantageous programs and a daemon that tries to match the list to data on the system.

Sure, they might offer some kind of bandaid for systems operated by people who do not have the necessary knowledge to operate a computer, but it is first and foremost a security theater and it does more harm than good by providing a false sense of security.

There are two solutions to the problem by the way. The former is educate the users and the latter is to switch to linux. No, seriously. The important part isn't linux, but switching away from a monoculture preferably to a desktop environment that is ruled by at least 3-4 systems that are different from each other and they are interoperating in well defined ways with each other. That way, you can get the platform (the systems it can possibly infect) down for a virus to a threshold where the percentage is simply too low for it to be able to spread.

Re:The example they give is wrong

[tgd]

There's a billion PCs in the world -- if you think four OS's sharing 25% of that market makes it too small to be of interest to criminals, you're nuts.

Monoculture is not the problem, although its a convenient flag to fly when "free as in beer" and "windows sux0rs" runs out.

Re:So what?

[Warbothong]

I remember watching an episode of the BBC's (very Microsoft dominated (as in, something major happens with Linux or Ubuntu or whatever, nothing. Some low-down Microsoft employee makes a comment about something he thinks might possibly someday become slightly relevant to some tiny niche and they spend 10 minutes on it)) Click program ( http://www.bbcworld.com/click ) and they had some "experts" (read: marketing guys) saying what the benefits of dual-core CPUs could be. All they could come up with was "You can use one core to do all of your normal activities, and use the other core to run antivirus and antispyware and firewall software constantly".

I almost cried.

News flash!

[achurch]

In a multitasking system, you can read and write the same memory space at the same time! . . . Oh, I guess it's not news after all.

Seriously, this is just Yet Another Race Condition. As long as you follow the rules of multithreaded programming (which for syscall wrappers means copying your arguments, since you can't negotiate mutexes with the caller), this is a non-issue.

Neeext!