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..."
Yes, it's important to be proactive. No, such a difficult and obscure attack is not something that is priority one.
FanFictionRecs.net
Does the system call wrapper run at kernel privileges (or some elevated level giving protection from the caller), or at the privileges of the calling process? If the latter, it is of course worthless. If the former, I'm not sure how you can modify values stored in privileged space before they're sent off to the original code.
Multiprocessor systems are marginally easier to exploit since they do not require forcing kernel context switches via paging or other techniques. However, I was able to successfully bypass the same wrappers on uniprocessor systems. I did my experimental work on Intel hardware, but they should work across a range of hardware architectures and configurations.
Looks like a variation (or maybe a dup) of this.
You see, Its these kind of computing professionals that make me feel like a fraud when people call me a computer genius.
Stop raising the bar you tool!
That's you, though. Most people believe that because they have anti-virus software they CAN safely run anything. I still find it an amusing shame that people are so willing to accept the huge performance penalties of anti-virus and now anti-spyware/adware for their utterly broken OS. Intel and AMD have to love this arms race.
(Insert Brand Name) Anti-Virus 2008: Multi-Core version (+$25 extra per core)
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.
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.
It takes a man to suffer ignorance and smile
Be yourself no matter what they say
You're ignoring the installed base of the OS. When Linux is as popular as Windows then the people writing malicious software will target it as well. They're doing it to make-money/steal-information off of you, Windows is the target now because it offers the highest return on investment. Once the Linux platform is widely popular then security tools will become relatively more necessary for it too.
Shh.
Now, I know nobody likes to be caught Reading The Fine Article, but it's maybe worth pointing out that according to The Fine Article, the exploit was demoed on Linux, FreeBSD, NetBSD, and OpenBSD. No mention of any other specific OS, though Watson did say "They should apply equally well on other operating systems".
I almost cried.
The article talks about wrapping OS calls to any process, and I don't think that's something Windows can really do. Yes, there is a limited hooking facility, but I don't believe there is anything that allows a user app with admin priviledges to effectively create a subsystem on top of a subsystem, which is what this application does. There are root kits that do this sort of thing on a single call, but arranging that is rather laborious. Really, the Windows kernel just isn't accessed with a single syscall...
This is my sig.
It works on any multiprocessor, including an
IBM 360/168 mainframe, where I first encountered it.
--dave
davecb@spamcop.net
I saw the same thing, and I had the same reaction. I still think of it every now and then and having another little laugh to myself.
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
It's called a race condition and can/has affect every OS that has SMP capability.
"I use a Mac because I'm just better than you are."
I still find it an amusing shame that people are so willing to accept the huge performance penalties of anti-virus and now anti-spyware/adware for their utterly broken OS.
AV software isn't protectng your from problems in the OS, it's protecting you from problems in the user.
No amount of OS security can stop the user from deliberately doing something stupid - nor should it.
BTW, here's that missing 'ed' from the previous post.
"I use a Mac because I'm just better than you are."
I am TheRaven on Soylent News
Congratulations! This is the first time I've ever seen someone use nested parentheses in non-code. You win a set of extra parentheses keys (because (as I've noticed) you seem to use them a lot).
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!
Slava Pestov
;)
That guy is a joke... I'm sorry dude but this guy is nowhere near the level of Watson. The numerous logical fallacies he consisently makes in his various IRC and forums posts are quite saddening. I'm sorry but some guy that says that "Latex [wrong spelling by him] and Docbook [other wrong spelling] are equivalent" is nothing but a clueless fool. That Slave is a joke... He's some FP zealot clueless when it comes to OOP/OOD/OOA (go to comp.object Slava and post there for a good laugh about your IQ level). JEdit has no place in my world where I use IntelliJ IDEA (commercial) and... Emacs (eat that Slava FP zealot
So, yup, he happens to know Java programming and FP... But he's a complete idiot out of his field and I've proved him wrong on countless occasion on various IRC forums. He's actually so pathetic that he'll leave the chatroom once you prove him by logical reasonning that he's a big-mouthed fool.
But we live in a world of mediocrity where mediocre people admire mediocre people and mediocre programs made by these mediocre people.
Slava is a fake, just as Joel.
Reading your silly post I actually think the real name of the silly anonymous coward is actually "Slava Pestov".
Oh and btw the leaders of "multicore/multiprocessor revolution" [sic] are actually hardware engineers... Slava's random fartings are nothing compared to this.
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.
Is it just me, or does this sound like a glorified rootkit? There is something called "Bluepill" that uses the hypervisor mode on new hardware to insert what essentially is a mega rootkit into the system that can intercept (and modify/drop) kernel calls. I'm not nearly as computer savy as most people here, but this is what it sounds like. If this is the case, this is old news. Also, the article mentioned that it was a problem on single-core processors, so the title is misleading.
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.
That summary made my head hurt. Stupid taco.
Nothing really new here.
:-)
Other attacks include DMA into buffers already provided to the kernel (lots of fun with async disk and network I/O), GPU writes, OS callbacks (depends on the OS in question), and even plain vanilla threads.
The kernel (or whatever secure subsystem you're talking about) needs to copy and verify parameters. This stuff has been known for decades. That doesn't stop weak software from being written, but it does give old farts like me a chance to kvetch
Any sufficiently advanced technology is insufficiently documented.
You must be new here, 'cause I see it all the time.
"[Regarding the 'cloud,'] ownership was what made America different than Russia." -- Woz
This is the first time I've ever seen someone use nested parentheses in non-code.
This from a Slashdot reader with a 5 digit UID?
Either you're lying just so you could make the joke, or Alzheimer's is setting in.
-
- - You can't take something off the Internet! That's like trying to take pee out of a swimming pool.
Fuck no. I could deploy a thousand Linux machines and never have to use the same distro/kernel/config twice. Linux rulez man!
"It doesn't cost enough, and it makes too much sense."
Not true. Messaging passing OS's and even BSD's without syscall wrappers enabled don't suffer from the problem.
Awesome furniture, accessories and cabinetry in Santa Rosa, CA: http://humanity-home.com/
FTA 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.
What's this about attacking multi-core processors?
The processors aren't broken, you could race a process in a uni and SMP system just the same. And in reality, your syscall security should be in there kernel itself, where any copies taken of data are passed internally to the required functions after policy checking.
Someday, I'll have a real sig.
We're all hypocrites. We all have hidden parts, it's the contrast between them that make us more a hypocrite than others
Your correct sir, its a dupe.
:) rather then discussing whats a very interesting class of security problems.
The amusing thing is that both times the summary and resulting discussion has been completely silly (people read the papers right?
The first submission lead people to believe that it was some kind of vulnerability in OpenBSD when its really a whole class of security problem affecting any kind of process that attempts to trap the system calls of another for the purposes policy verification.
The second summary completely munged the technical details. perhaps the third one will be charmed?
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.
The first submission lead people to believe that it was some kind of vulnerability in OpenBSD when its really a whole class of security problem affecting any kind of process that attempts to trap the system calls of another for the purposes policy verification.
It's not a new class, CVE-2006-0457 is in the same category, for instance.
It's not even restricted to SMP. Some of the more clever hacks will work on a uniprocessor system by retrying until a context switch happens at just the right instant (or wrong instant depending on your perspective). They may stack the deck in their favor by arranging for a function call to cause a page fault. It's certainly easier to exploit with multiple processors.
The one certainty is that this form of attack is nothing like new.
Of course, many syscall wrappers can be bypassed by coding a syscall directly in assembly language rather than calling a library function.
The crux of the problem for ptrace based systems is that some syscall parameters are stored in user memory. Consider the open call in an environment using ptrace for security. I write a multi-threaded app and create a buffer holding the filename. I set it to "/some/path/thats/ok" and call open. The ptrace process is notified of the call, accesses the filename parameter in my thread's memory and decides it's OK, so it calls ptrace to allow the syscall to happen (rather than nullifying or killing my process).
IF my second thread can change the filename buffer to "/some/path/I/shouldnt/be/allowed" between the moment that the tracer decides it's OK and the moment it calls ptrace to allow it , the kernel will open the file for me and I have bypassed security.
On a uni-processor system, I might have to make a great many attempts, but with persistance, eventually my second thread might get scheduled at just the right moment to make the change. If I succeed once, the billion failed attempts won't matter.
The central problem in this instance is that ptrace was intended to be a debugging interface and not a security measure.
Solving that problem could get quite complex. If the security measure must also validate data written (which could potentially be several GB), the kernel would have to make sure that no thread in any process that has access to the memory the syscall covers can be scheduled AND that no other ptrace parent of those threads can be scheduled. It can do that by walking process structs under a lock (expensive) or temporarily marking the affected pages R/O and blocking on a fault (also expensive on most archetectures). Even if such a measure is taken, it shouldn't apply to a normal ptrace since it would significantly change the behaviour of a program being debugged.
The difficulties above are why all files that can be accessed by a system that can access classified data must also be treated as classified no matter what they are. Otherwise a badguy might manage to stuff a blob of top secret data into an unclassified file for later retrieval. Just imagine the nightmare of attempting to track classification level page by page and proving it can't do the wrong thing.
It's related to the reason that no DRM scheme can ever provide absolute protection against a sufficiently determined copier.
If the security is limited to parameters that have a more sane maximum size (such as a filename where MAXPATHLEN is a set value), the kernel could copy the parameter first and provide it to the tracer process using a different syscall.
From a more theoretical POV, any OS kernel that unwisely relies on a parameter in userspace not changing between the time it validates access and the time it fulfills the request can even have it's internal access controls violated or end up getting crashed on an SMP system. That's one reason why modifying a kernel meant only for uniprocessor systems to support SMP is VERY non-trivial.
Yes this is why I did not say for instance "a whole new class" ;)
You are welcome on my lawn.
Way back in the 1970's folks I worked with were hired by IBM to form a tiger team to attack VM/370. (Virtual machine OS's have been around since the 1960's.)
They were able to crack the system by setting up a DMA based read. Then they called the kernel with some kernel call parameters. The kernel checked the parameters. And then the DMA input rolled new values onto those parameters.
This, of course, took some careful timing.
And it relied on kernel weakness - the weakness of leaving the user parameters in user accessible memory while they were being validated. The fix was to have the kernel move the call parameters into its own memory before validating.
And on a multi-CPU unit (those, too, existed back then) that copying of system call parameters had to be to a different place for each CPU, else synchronized calls from different CPU's could be a weakness.
You'd probably get a BSOD before it can do any harm.
hackerkey://v4sw5/7BCHJMPRUY$hw3ln3pr6/7FOP$ck6ma8+9u6L$w4/7CGUXm0l6DLRi82NCe3+9t5Sb7HMOPRen5a17s0DSr1/2p-3.62/-5.23g3/5
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.
So, this doesn't protect UP systems at all. preempt already exposes you to these kind of concurrency issues, and one can only assume that pretty much any RT OS also is vulnerable.
Unless I'm misunderstanding the issue, this seems like a completely irrelevant exploit. More accurately, it seems to be about the least efficient way possible to achieve this goal. If you already have injected virus code running in a separate thread inside a process, you don't have to intercept the system call and overwrite the data at all. You can just ask the system to grant write permission to the TEXT pages and change the system call to call into your own function that mucks with the values, calla the system call, and returns the result. For that matter, you could rewrite the code to not call the system call at all and just always return "not infected". You could also patch around the verification function entirely and then overwrite the data at your convenience.
Doing such an exploit with a timing attack just doesn't make any sense. Once you have untrusted code running in your address space, your process must be considered untrustworthy anyway. This is why we have processes instead of just running everything on multiple threads in the same process. Once those boundaries break down, you're screwed even if you could prevent that race condition, as the code and data could be manipulated at any other point along the way.
Indeed, the ability to debug software depends on this race condition. As I understand it, system calls and possibly function calls are the only guaranteed safe points for attaching to an unknown process and stopping it. If you were to eliminate the ability to stop a process or thread on entry to or exit from a system call, your ability to debug would go south rather rapidly.
Check out my sci-fi/humor trilogy at PatriotsBooks.
I do read a lot more digg than I use to. That is probably the same as having a debilitating neurological disease.
Yeah, apparently people speak with a lisp a lot....
(Anyone who has used lisp would get the joke I was trying for)
If I have nothing to hide, don't search me
Just to point out, or re-emphasize, that the exploit is possible due to the nature of the software (the operating system, in this instance) and not because of a flaw in the hardware, per se.
Dude, it's all about delivery.
Qxe4
Yeah, that'll be why the example exploit code fails.
There are places where the networks are not touching,and there are places where they are-Boeing's Lori Gunter
Yeah, just wait until people run non-Windows machine as web servers and the like, it's gonna be chaos !
There are places where the networks are not touching,and there are places where they are-Boeing's Lori Gunter
This isn't a problem in non-Microsoft OS, is it?
Armaments, 2-9-21 And Saint Attila raised the hand grenade up on high, saying, 'O Lord, bless this Thy hand grenade' N
No way, man. Edward Dijkstra built the first navigation system, Tommy Hoare invented the algorithm and Ronald Knuth wrote the Morris-Pratt worm, which later evolved into ILOVEYOU and Sobig.
Ha! And the professor had me fail the Computer History class! I still know everything!
USE HOT GRITS WITH STATUE OF NATALIE PORTMAN (NAKED AND PETRIFIED)
While there are potential problems, he doesn't say which systems.
The article mentions *nix based systems, but talks about Anti-Vir sw that layers on top of the
OS. The layered AV SW, sounds like a windows problem.
While there are race conditions possible with many security solutions due to the fact that they are not bound into the kernel, none of the problems are new with "multi-core" than with other "MP" machines (computers did have multiple "Cores" (CPUs) in the past -- just not on one chip).
The article is very vague about what systems this affects, but if a module is properly implemented using the linux security module framework, it won't be affected by this problem. The only time/place where this affects modules is in close-source environments where they can't both decode *and* use the arguments without re-enabling interrupts within the same process.
"Systrace" (mentioned in base article), has been known to suffer from this problem for years (before
Dual Core existed). But I thought it was (from the name) more intended to be a tracing tool/diagnostic for use in "friendly environments".
No one will need to fix anything unless they are required to (by law or by monetary considerations). This isn't a problem the average home user would have to deal with from the internet, *usually*, and even if it happens what you wanna bet that no changes will come down the line until they are required by some "customer". Maybe a government security involved contract would require this, but how many of those require network security in a hostile environment? i.e. usually if security is required, it's not directly on the internet.
Case in point -- last evaluation I heard for Windows only involved it being tested as "secure" in a non-networked configuration. You want security? Don't let strange code, data or people on your computer...but the minimum required, disabling web-scripting, by default, is too much trouble for most people (I still have it turned off, but I'm willing to not have things magically work to be safer).
I don't see how this is 'news'...except for those who weren't awake last time this was discussed.