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..."
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.
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".
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.
Yes. Not having a mainstream OS to replace Windows with, but instead fragmenting the operating system landscape would eliminate a lot of problems. Pretty basic disease control principle: breed and use multiple types of plants and animals, so that any single disease can't kill off everything.
It takes a man to suffer ignorance and smile
Be yourself no matter what they say
Erm, no, you don't need to be root to exploit these attacks, you just need to be in a situation where some security is provided by syscall wrappers. Such wrappers are sometimes used to provide an additional layer of security for applications and services; providing additional limits to what files can be read and modified, what executables can be ran, where sockets can be bound and so forth, and importantly, logging when attempts to breach these policies are attempted. You're exactly one buffer overflow away from such an exploit being a problem, since it makes that layer useless against a clueful attacker.
That so many people are finding this attack surprising is probably a sign that there isn't enough appreciation for the security implications of concurrent systems (even if they've been known by security conscious people for many years), and that we might be finding more attacks based on them in future as more people become aware of them.
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.
From Common Driver Reliability Issues: User-Mode Addresses in Kernel-Mode Code
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.
I'm not convinced that "virii" counts as a portmanteau, which generally requires that the sound and meaning of two words are preserved.
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)
Could someone explain this to me some more. In order for thread2 to write to buffer1, there must be a page table entry mapping buffer1's physical address into thread2's virtual address space.
Are the operating systems allowing thread2 to arbitrarily change its PTEs? That sounds like the problem right there.
Education is a better safeguard of liberty than a standing army.
Edward Everett (1794 - 1865)
Since the NT kernel is preemptable this would be a problem even on single CPU machines
From the Article (emphasis mine):
"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."