Month: June 2011

The segmentation functionality has been present on the Intel processors since early stages of the CPU manufacturing. In real-mode, segments were the basis of 16-bit memory management, allowing the operating system or application to specify separate memory areas for different types of information, i.e. code, regular data, stack and so on. When a more complex and powerful Protected Mode was introduced in the x86 processors, the usage (meaning) of the six segment registers was completely re-designed. From this point now on, these registers would no longer hold an explicit memory offset (as in real-mode), but instead they would be used to store so-called Segment Selector values, which are in turn pointers into one of the two segment descriptor tables: GDT or LDT (Global / Local Descriptor Table). Because of the introduction of another memory-management mechanism (paging), a great majority of the modern, main-stream operating systems don’t make extensive use of segmentation; they usually initialize GDT with trivial entries (e.g. base=0x00000000, size=0xffffffff), and then completely ignore the existence of segments (except for user ↔ kernel transitions). What is most important, however, is that even though the mechanism is ignored by the OS design, the systems make it possible for an application to set up its own LDT entries (e.g. sys_modify_ldt on Linux, or NtSetLdtEntries on Windows). Consequently, any process can locally make use of segmentation for its own purposes – e.g. in order to implement a somewhat safer execution environment, or other purposes.

More detailed information about segmentation and GDT/LDT management can be found in Intel 64 and IA-32 Architectures Software Developer’s Manual: Volume 3A: System Programming Guide Part 1, and GDT and LDT in Windows kernel vulnerability exploitation by me and Gynvael Coldwind. Any considerations made further in the post are provided with regard to the Windows operating system, which is the main subject of this write-up.

Read more

As usual, I would like to inform you that the sixth issue of the Hack in the Box Magazine has just been published. Unlike previous editions, the paper is released several weeks after the HITB Amsterdam 2011 security conference – we spent the additional time working on providing you with even more interesting sections and articles. Despite the strictly technical articles (covering Web, Network, Linux, Windows and Application security areas), you can also find two unique interviews: one with the Facebook CSO Joe Sullivan, and the other one with Chris Evans and Adam Mein (members of the Google Security Team), discussing a variety of advantages, disadvantages, issues and benefits related to the famous Vulnerability Reward Program.

What shouldn’t be much of a surprise, the Windows Security section contains an article of mine, called Windows Numeric Handle Allocation In Depth. In the write-up, I have thoroughly described the allocation and deallocation algorithms, used by the Windows kernel to assign numeric identifiers (handles) to various types of hardware and software resources. As it turns out, the research might have a significant impact on an interesting (yet, not very well known) software vulnerability class, called Handle-based use-after-free condition. The details of such a vulnerability were to be made available within one week, however Microsoft has postponed the release date of several of my security advisories. Therefore, a detailed blog entry explaining the intricacies of an example flaw of this type is going to show up at my (MS?) earliest convenience. Well.

Oh and by the way, as some of you may already know, that I am soon moving to Zurich, Switzerland… Wish me luck on my new path of life :-)

Read more

A nearly year ago, a critical Windows Shell vulnerability was found in the wild (stuxnet & co), making it possible for an attacker to execute arbitrary code on a victim’s computer, by getting the user to list a directory which would contain a specially crafted .LNK file. The sole purpose of files of that type is to provide shortcut functionality – i.e. allow the user to reference various system resources (most often – executable files) through link files, instead of using the full path of the resource. Since EXPLORER.EXE makes every effort to make it even easier for the user to recognize the resource being pointed at, it displays the original resource icon (if any) as the shortcut’s one. In order to obtain the picture in the first place, the Windows Shell would sometimes call LoadLibrary on the referenced module, which would result in the execution of the library’s standard DllMain routine. What should be noted, is that LoadLibrary was usually called on legitimate Control Panel executables, but it turned out that the LNK format allowed to specify virtually any PE image as a CP module, resulting in immediate and 100% reliable execution of potentially malicious code.

What I would like to present today, is a low-impact flaw found in the LNK-parsing routines present in the SHELL32.DLL module, extensively used by EXPLORER.EXE. Exploiting this issue might result in – at most – Denial of Service conditions, or disclosure of random heap bytes from the Windows Shell process memory (which is not a big deal, considering that the user can read EXPLORER.EXE memory, anyway).

Read more

(Collaborative post by Mateusz “j00ru” Jurczyk & Gynvael Coldwind)

Early Sunday morning discussion has resulted in j00ru coming up with an idea to mitigate some variants of kernel exploitation techniques by introducing a CPU feature that would disallow execution control transfers in kernel-mode to code residing in user memory area pages (e.g. addresses < 0x80000000 on a 32-bit Windows with default settings). The idea was that the system would mark every page as either being allowed to execute code in ring-0 or not. And hey, guess what… Intel has already proposed such a feature a month ago! Furthermore, it seems that this exact idea was already described in 2008 by Joanna Rutkowska, and two days ago she has published a follow up post on her blog.

The feature is called Supervisor Mode Execution Protection (SMEP for short) and it is documented in the newest release (May 2011) of the Intel manual 3A sections 2.5 (CR4.SMEP flag) and 4.6 (per memory page settings). For convenience reasons, we have quoted the related parts at the end of this post. Also, Dan Rosenberg has already (May 16, 2011) discussed, how this feature will interact with Linux and its specifics. To contribute to the discussion, we decided to do a similar write-up, and describe the implications of SMEP on Windows (and possible ways of bypassing it).

Read more