The world of multi-core cpus we have 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 antivirus 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 careful written exploit can attack in the little timeframe 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.
Watson presented his work at WOOT07, USENIX Workshop on Offense Technology, the results of his research entitled "Exploiting Concurrency Vulnerabilities in System Call Wrappers".
During the talk he showed how concurrency can be used to bypass security protections applied by so-called syscall wrappers.
A system call, briefly called syscall, is a basic function in the kernel that is called by a program. For example, when you open a file it's highly probable that the software you are using called the open()
syscall to open it.
A sycall wrapper sits between the kernel and the program itself, and analyzes which syscalls are called and their arguments. A security wrapper might be configured to block access to some files, so in the previous example trying to open()
the file "secrets.txt", it may stop the operation and return an error to the application.
We contacted Robert to learn more...
How does the attack work?
System call wrapping is a widely-used technique for extending kernel security, found in anti-virus systems and security policy enhancement frameworks such as the GSWTK, Systrace, and CerbNG systems I examine in the paper. System call interposition allows code running in the kernel address space to "wrap" system calls, adding new security checks, replacing the values of arguments to virtualize name spaces, or to audit arguments for the purposes of logging or intrusion detection. It's a very flexible technique, and appealing to software authors because it doesn't require changing existing kernel code, and allows control at the very well-understood system call interface.
This attack targets a weakness in the system call wraper architecture, in which system call arguments are separately copied by the system call wrapper and the kernel, allowing the attacker to "race" to replace the argument values between copies.
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.
The existence of some of these vulnerabilities has been known for years (Ghormley 1998, Garfinkel 2003, Watson 2003), and I approached the authors of many of these wrapper systems as early as 2002 to report the problems. The contribution of this paper is in analyzing the vulnerability class, thoroughly exploring the attack space (I identify two previously undiscussed classes of race conditions, one of which is more broadly applicable), and to explore exploit strategies, allowing us to reason about the effectiveness of this attack aproach. It turns out that the approach is very effective indeed.
The paper [PDF] provides both a detailed discussion of the general class of concurrency vulnerabilities, and more concrete discussion of these specific vulnerabilities. I'd refer readers especially to the pictures and code in the slides [PDF] associated with the talk, which should make both the attack approach and simplicity of the exploits clear. In less than 20 lines of C code, and using only standard OS calls for memory access and management, the wrapper protections were completely disabled.