The first edition of the NoSuchCon security conference held in Paris ended just a few days ago. Before anything else, I would like to thank all of the organizers (proudly listed at nosuchcon.org) for making the event such a blast! Both the location, venue and speaker line-up were amazing, with lots of free beer and wealth of people to chat with. Overall, I am very happy to have shown up there and I will definitely make sure to attend the second edition of the conference.
Other than drinking, discussing 0-days and visiting Paris, I also had the pleasure to give a talk about the usual subject – Windows kernel security. The exact title of my presentation was “Abusing the Windows Kernel: How to Crash an Operating System With Two Instructions“, and touched on the subject of several different exploitation techniques, internal CPU related behavior and security vulnerabilities (all related to the Windows operating system) that I discovered during the course of last several weeks / months.
While the slide deck was made available to the attendees right at the beginning of my talk at nosuchcon.org/talks (great idea!), I’m reposting them here anyway, in case you haven’t had a chance to take a look yet. In fact, a majority of the talks were interesting and highly technical, so be sure to check the available material for all presentations ;-)
Slides: “Abusing the Windows Kernel: How to Crash an Operating System With Two Instructions” (3.3MB, PDF)
KiTrap0e advisory: “Abusing Windows NT #PF Trap Handler to Bugcheck and Leak Information”
I originally planned to address six separate topics, but due to time constraints I decided to skip some of them in favor of the other ones. A brief description of each technique and vulnerability follows below.
- “nt!memcpy (and the like) reverse copying order” – certain implementations of the memcpy, memmove, RtlCopyMemory and RtlMoveMemory found in the kernel and third-party drivers alike handle the “overlapping regions” corner case by reversing the copy process order from the intuitive left-to-right to right-to-left direction. By starting to write at the end of the destination memory region, the functions facilitate successful exploitation of certain buffer overflow vulnerabilities, by allowing a (relative) write-what-where condition to be provoked.
While the technique works best for a kernel ← user copy on 64-bit platforms, it can also be applied to a number of other scenarios. For more information, please refer to the “Memory Copy Functions in Local Windows Kernel Exploitation” article published last year in the Hack in the Box Magazine, Issue 009. The Proof of Concept source code of a vulnerable device driver and an exploit used during live demonstration can be found at memcpy_ioctl.zip (3.9kB, ZIP). Note that the code has only been confirmed to be suspectible to a stack cookie bypass when built with WDK 7600.16385.1 for Windows 7 (x64 Free Build), although it should generally work for any 64-bit target.
- “nt!memcmp double-fetch” – an interesting behavior found in the Windows 8 32-bit implementation of the nt!memcmp standard function, making it possible to fake matching regions when a user-mode pointer is passed as one of the function’s parameters. Due to lack of time, this was not covered at NSC; however, our SyScan’13 slides and paper explain the problem thoroughly.
- “PAGE_GUARD and kernel code execution flow” – a technique already described in the “Fun facts: Windows kernel and guard pages” and “A story of win32k!cCapString, or unicode strings gone bad.” blog posts.
- “SegSs, LDT_ENTRY.HighWord.Bits.Default_Big and IRETD” – due to how the “Big“ LDT entry flag in the SS: segment descriptor is handled by the IRETD instruction used for cross-privilege-level transfers in Windows, it is possible to have the CPU disclose the upper 16 bits of the current thread’s kernel stack pointer in 32-bit versions of Windows.
Proof of Concept source code: small_seg.zip (1kB, ZIP).
Example output: Z:\>smallseg.exe [+] High word of kernel stack address: 94070000 Z:\>smallseg.exe [+] High word of kernel stack address: 94010000 Z:\>smallseg.exe [+] High word of kernel stack address: 956b0000
- “Windows 32-bit Trap Handlers” – the lack of proper sanitization of the previous CPL inside several trap handlers used in 32-bit Windows can be leveraged to disclose addresses of several internal ntoskrnl.exe (or equivalent) symbols in the kernel address space, effectively defeating kernel ASLR (not that it matters much for this particular OS).
Proof of Concept source code: kitrap01.zip (1.3kB, ZIP) and kitrap0e_addr.zip (1.4kB, ZIP).
Example outputs: Z:\>kitrap01.exe [+] Kernel image base: 8320c000, size: 413000 [+] Iteration 3d000 / 413000 [+] nt!KiFastCallEntry address: 83249790 Z:\>kitrap0e.exe [+] Kernel image base: 8320c000, size: 413000 [+] Iteration 3d000 / 413000 [+] Leaked address: 8324984c [+] Leaked address: 83249887 [+] Iteration 41000 / 413000 [+] Leaked address: 8324d4ed [+] Iteration 412000 / 413000
- “Crashing Windows and leaking bits” – the primary focus area of the overall talk. As it turns out, the nt!KiTrap0e #PF trap handler trusts the KTRAP_FRAME.Ebp field to be a valid kernel-mode pointer when processing faults occuring at a specific, magic Eip values. Again, due to lack of proper KTRAP_FRAME.SegCs sanitization, it is possible to craft a frame with controlled Eip and the user-mode Ebp register, allowing a local attacker to crash the system via an invalid memory reference, or otherwise disclose the least significant bit of any byte in the kernel address space.The two instructions capable of crashing all 32-bit Windows NT-family systems as of today are as follows:
xor ebp, ebp jmp 0x8327d1b7
where 0x8327d1b7 is the nt!KiSystemServiceAccessTeb address.
Proof of Concept source code: kitrap0e_bsod.zip (0.5kB, ZIP), kitrap0e_leak_bits.zip (1.4kB, ZIP) and kitrap0e_addr_space.zip (1.5kB, ZIP). The programs unconditionally crash the operating system, allow disclosing specific bits of the kernel memory and scan the kernel address space layout, respectively.
"To je přiznaná vlastnost" je ta nejhorší výmluva na vlastní neschopnost. Aneb proč Dotyk nikdy nebudete mít
(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 ;)
During the whole two days (they stopped just for a nap break), the teams competed in task-based CTF. The organizer of the contests was a well-known Dutch team named Eindbazen, which took part in PHDays 2012 and has been invited to PHDays III.
Some of Eindbazen also participated in HITBSecConf CTF as members of other teams. hack.ERS being one of such teams took second place. Third place went to More Smoked Leet Chicken, a Russian team that consists of former Leet More and Smoked Chicken. Note that it was the Leet More members who won PHDays CTF 2012.
Almost at the very beginning [TechnoPandas] came to the fore preventing other participants from taking the lead and, eventually, took first place. However, hack.ERS and More Smoked Leet Chicken were found struggling hard for second place.
HITBSecConf is a conference devoted to information security issues. The conference is held twice a year: once in Amsterdam and once in Kuala Lumpur, Malaysia. In April in the capital of the Netherlands, the fourth conference was held. Apart from CTF contests, the program included numerous reports and hands-on labs oriented towards different aspects of information security.