(Collaborative post by Mateusz “j00ru” Jurczyk and Gynvael Coldwind)
A few days ago we (Gynvael and I) gave a talk during the SyScan’13 conference in the fine city of Singapore, and as promised (though with a slight delay), today we are publishing both the slide deck and a white paper discussing memory access pattern analysis – a technique we recently employed with success to discover around 50 double-fetch vulnerabilities in Windows kernel and related drivers (Elevation of Privileges and Denial of Service class; see Microsoft Security Bulletins MS13-016, MS13-017, MS13-031 and MS13-036 released in February and April this year. Also, stay tuned for more security patches in May and June).
In our SyScan presentation, we explained the concept of kernel race conditions in interacting with user-mode memory, gave a brief rundown on how they can be identified by using CPU-level instrumentation of an operating system session, and later focused on how they can be successfully exploited with the help of several generic techniques (on the example of three Windows vulnerabilities discovered by the Bochspwn project). While we only had the time to go through a single case study (the CVE-2013-1254 vulnerability in win32k!SfnINOUTSTYLECHANGE), both slides and the paper contain a detailed analysis of another local privilege escalation: CVE-2013-1278 in nt!ApphelpCacheLookupEntry, and an amusing case of a double fetch behavior (it is not clear if it can be classified as a bug) found in the default kernel implementation of the standard nt!memcmp function, as a bonus.
We hope you will enjoy both the slides and whitepaper – considering the amount of time we have dedicated to the research, we would really appreciate your feedback.
Slides: “Bochspwn: Exploiting Kernel Race Conditions Found via Memory Access Patterns” (2.6MB, PDF)
Paper: “Identifying and Exploiting Windows Kernel Race Conditions via Memory Access Patterns” (1.0MB, PDF)
Please note that we are not releasing the Bochspwn project at this time – we are planning to open-source it later this year. On the other hand, the demo videos for the CVE-2013-1254 and CVE-2013-1278 vulnerabilities shown during the talk are now available online:
The SyScan event itself was really fun – the speaker line-up was one of the best ones we have seen this year, ensuring high technical quality of the talks (which they were in fact quite inspiring), with nothing lacking on the organizational side. We were also positively surprised by the city-state of Singapore – it’s really a modern, clean and friendly place! We had a great time there and hope to visit it again soon ;)
22 thoughts on “SyScan 2013, Bochspwn paper and slides”
Use double memory access on page boundaries to exploit Kernel syscalls: I read your post and the introduction of PDF article of your awesome work. I think that your considerations and job is ingenious and very talented.
Thanks very much for sharing it….
Are you going to introduce something like this at NosuchCon conference?
I look forward to meet you and listen personally the presentation…
How on earth did you get 64-bit Windows to run in Bochs? I just get bluescreens when I try. I’d love to know this as I’ve been trying to get it to work in QEMU for some research with no luck.
@Andrea: Thanks! At NoSuchCon, I am going to be presenting a slightly different research :) You shall find out soon.
@Brendan: I dropped you an e-mail.
69 pages paper – guys, you should definitely write a book about windows security :)
I agree with mgrzeg, you should write a book about windows kernel security and exploitation. excellent work, as always.
I got 2 questions for you.
1) Have you seen the presentation about VirtICE that was held at blackhat 2010? http://media.blackhat.com/bh-us-10/whitepapers/Anh/BlackHat-USA-2010-Anh-Virt-ICE-wp.pdf
2) Is it possible to make any comparison between yours and their approach, even though you do not have their tool (I assume)? Do you see any benefits of using Qemu instead of Boch, for example?
Considering to make my own tool/framework for this and wonder which way to go. Why did you pick Boch?
@Ani: yes, we heard about the research. We decided to use Bochs because it is by far easier to write instrumentation for, i.e. it has a very intuitive and simple instrumentation API, documentation and examples you can use to cleanly and elegantly implement the desired logic. As far as we are concerned, hacking on qemu is much more difficult because of lacking instrumentation support and horribly written code.
Can you share exploit source code?
Comments are closed.