nt!NtMapUserPhysicalPages and Kernel Stack-Spraying Techniques

Although not the most common vulnerability class, it sometimes happens that a ring-0 module (or the kernel itself) references a local variable or buffer, which wasn’t previously properly initialized. The threat is usually mitigated by compiler warnings / errors, informing about potential security flaws present in the source code – as life shows, it is not always enough to avoid serious vulnerabilities of that kind. Having the knowledge about a buggy function, one might stumble upon a serious problem – how to actually make use of the information in a beneficial way (e.g. execute code in the security context of the faulty function – here, kernel-mode). The problem actually boils down to another matter – how can one control the trash bytes present on the ring-0 stack, from within a ring-3 perspective. It is primarily caused by the fact that each thread present on the Windows platform has two separate, dedicated stacks – a user- and kernel-mode one. Such security design obviously limits any possibility for an application to poke with the execution path of a highly-privileged code. Unfortunately, it also narrows down the amount of controllable data, which the user is able to (indirectly) move to the ring-0 stack… or does it? In this post, I am going to focus on my recent, minor discovery, which makes it possible to insert large amounts of arbitrary data into the stack memory areas of the current thread.

In the remaining part of the post, an assumption is made that the faulty device driver code runs in the same thread context as the code that actually triggers the vulnerability.

Read morent!NtMapUserPhysicalPages and Kernel Stack-Spraying Techniques

Subtle information disclosure in WIN32K.SYS syscall return values

While performing some random research related to the WIN32K.SYS driver syscalls a few months ago, I stumbled on an interesting finding – when examining the full 32-bit (or in the case of the original research – 64) return values, some of the services seemed to return unusual numbers, for example 0xfffffa8000ea0000. After investigating the subject for a while, it turned out that a part of the WIN32K syscall interface indeed does not always return a value of the native CPU size (as opposed to the core NT kernel). Instead, some of the graphical services seem to be explicitly declared as:

VOID NtUserRandomService( ... )


USHORT NtUserRandomService( ... )

Funny enough to find such types of quirks in the Windows kernel, eh? A list of the flawed syscall names is as follows:

  • ETHREAD (full disclosure)
    • NtUserAlterWindowStyle
    • NtUserSetThreadState
    • NtUserNotifyWinEvent
    • NtUserModifyUserStartupInfoFlags
    • NtUserSetThreadLayoutHandles
    • NtUserNotifyIMEStatus
    • NtUserSetThreadLayoutHandles
    • NtUserSetRipFlags (Windows XP only)
    • NtUserSetDbgTag (Windows XP only)
  • ETHREAD (partial disclosure)
    • NtUserRegisterClassExWOW
    • NtUserGetKeyState
    • NtUserGetAsyncKeyState
    • NtUserVkKeyScanEx
    • NtUserSetWindowWord
    • NtUserSetClassWord
  • W32THREAD (full disclosure)
    • NtGdiEngUnlockSurface
    • NtGdiPATHOBJ_vEnumStartClipLines
    • NtGdiEngDeletePath
    • NtGdiEngDeleteClip
    • NtGdiFONTOBJ_vGetInfo
  • Other (unknown?)
    • NtGdiFlush
    • NtGdiEngUnlockSurface

Read moreSubtle information disclosure in WIN32K.SYS syscall return values

Pimp My CrackMe contest results

Around three weeks ago, Bartek announced a competition called “Pimp My CrackMe” on his http://secnews.pl/ website. The main prize was a free pass to the CONFidence 2011 conference, which is going to take place in on 24-25 May, in Cracow. The task was to create an interesting CrackMe program, which would then be judged based on its difficulty level (on the other hand, it had to be solvable), inventiveness of the applied techniques, and general visual presentation. Since I wasn’t yet registered on the conference at the time of the announcement, I decided to take part in the contest – traditionally, teamed up with Gynvael Coldwind. The final results were eventually declared yesterday evening; it seems that me made it to the first place ;)

There were three crackmes reported, in total – as Gyn says: It’s not bad, but I was hoping for a higher scene activity. What should be noted, is that based on the number of submitted programs, the organizer managed to get another two conference admissions, so that all of the contest participants are rewarded. Well done!

The complete results, together with the Jury‘s justification of the decision, is presented below:

  1. Mateusz “j00ru” Jurczyk & Gynvael Coldwind

    For an interesting approach to the serial number verification problem, technical aspects related to how the CrackMe works, and an unusual interface.

  2. hasherezade

    For a custom encryptor (and the effort put in making it function correctly), and an interesting verification algorithm.

  3. Grzegorz “haker500” Jastrzębski

    For the willingness of taking part in the competition and creating a CrackMe in assembly.

Read morePimp My CrackMe contest results