j00ru//vx tech blog

It gives me a great pleasure to announce that after several months past the last release (see The HITB Magazine #6 now available!), the awesome crew (as always, special kudos to Zarul Shahrin) has managed to put up the 7th edition of Hack in the Box Magazine! Without much ado, I will just say that the issue presents some interesting bits about the current global crysis in the cyberspace (by Jonathan Kent), extending SQL Injection attacks through buffer overruns (Aditya K Sood, Rohit Bansal and Richard J Enbody), automation of fuzzing and process crash testing with the PCMCA tool (Jonathan Brossard) and a number of other interesting articles and book reviews.

In order for the magazine to function properly, we are in constant need of unique content. If you believe you have some interesting, IT Security-related material to present, and would like to contribute to the project, don’t hesitate to drop us a line (editorial@hackinthebox.org)! We will be more than happy to consult your idea, help with the correction, or provide with any other type of advice :-)

As for the Windows Security section, you can traditionally find an article authored by me, titled Windows Security Hardening Through Kernel Address Protection. The paper briefly describes the problem of revealing potentially sensitive information about the kernel virtual address space into user-mode code, lists the scenarios in which such information might prove useful during practical exploitation, and proposes potential solutions on both Windows and CPU levels.

Read more

A few years back, we’ve been (i.e. j00ru and Gynvael) working on a bootkit-related project (some polish SecDay’09 presentation slides can be found here). One of its basic requirements was the ability to load custom boot-“sectors” from an external host in the local network. Since the publicly available solutions required too much time to be spent on configuration and we didn’t need most of the offered functionality anyway, we decided to create an extremely simplified Preboot Execution Environment (PXE) server on our own, and so PiXiEServ came to be. Actually, a great majority of the source code was written by Gynvael, with only few modifications applied by me.

Although we eventually haven’t managed to complete the said bootkit-related project and the server source code is dated back to October 2009, we’ve now decided that the program and its sources might prove useful to other people playing with the network machine booting mechanism, as well as trying to write their own OS and test it on both virtual and real hardware (without having to worry about getting old school floppies, CDs, etc).

Read more

Due to my forthcoming move to Switzerland, I haven’t had much time to post anything new here for quite some time. Hopefully, this will change soon after I am set up in my new location. In the meanwhile, I would like to share several tables presenting the differences in the export table symbols and native + graphical System Call Interface, found between a fully patched Windows 7 64-bit platform and the recently released Windows 8 Developer Preview. Since only x64 binaries are currently available to me, the tables are only based on this one architecture; I will soon supplement the set with 32-bit comparisons (as long as there are any changes between those two).

An example table (Windows 7 vs Windows 8 executive services) is presented below:

Read more

A rather short blog post today, as I am currently on my vacations. After publishing two, quite extensive write-ups regarding vulnerabilities in the Windows “CSRSS” component at Microsoft July Patch Tuesday:

• CVE-2011-1281: A story of a Windows CSRSS Privilege Escalation vulnerability
• CVE-2011-1282: User-Mode NULL Pointer Dereference & co.

I would like to shortly discuss the details about another bug in the Windows Subsystem, which was NOT patched due to low severity, and can be used to force a reboot of a Windows-driven machine. The result can be accomplished by exploiting a flaw in the winsrv!SrvGetConsoleTitle routine – a member of the Console Management services’ group. All Windows NT-family system editions up to Windows XP / 2003 are affected; on Windows 7, making use of the bug would crash the corresponding CONHOST.EXE process, at most. Even though it is also theoretically possible to turn the issue into an “Information Disclosure” class, we consider it highly unlikely to avoid an unhandled exception during the exploitation process.

Read more

After a short break, today I would like to present the details of another Windows CSRSS vulnerability, fixed during the recent Microsoft Patch Tuesday cycle (advisory MS11-056) – CVE-2011-1282, also called CSRSS Local EOP SrvSetConsoleLocalEUDC Vulnerability. Although not as spectacular as the previous one (see: CVE-2011-1281: A story of a Windows CSRSS Privilege Escalation vulnerability), I strongly consider the nature and reason of the flaw’s existence not less interesting than the lack of a basic sanity check in winsrv!SrvAllocConsole. Have fun!

Introduction

Before lurking into the strictly technical details related to the considered vulnerability, I would like to discuss some of its general charateristics. As stated in the original Microsoft Security Bulletins, the issue severity is Important in the context of Windows XP and 2003 (marked as the Elevation of Privileges class), and Low (Denial of Service conditions) on newer system platforms. This particular difference between the XP and Vista impacts is going to be addressed later in this post.

Read more

Today, I would like to present a detailed description of the CVE-2011-1281 vulnerability [1], which was reported by me several months ago and patched today, together with four other bugs marked as the Elevation of Privileges class, on the occasion of the monthly Microsoft Patch Tuesday cycle (see Microsoft Security Bulletin MS11-056, a summary of the flaws’ origin and severity). All of the issues were present in the Windows CSRSS (Client/Server Runtime Subsystem) component, already mentioned in several of my posts [2][3][4] and articles [5][6]. Some of these problems affected every edition of the Windows NT-family systems up to Windows 2008/7, while the remaining part was only present up to Windows Vista. The latter is primarily caused by the fact, that all of the flaws were found in the Console Management code present in winsrv.dll (one of the modules used by the Windows Subsystem). Due to some major architecture changes applied in Windows 7 [7], the console support was (almost) entirely moved from the privileged CSRSS process into CONHOST.EXE, running in the context of the local user.

The blog post is meant to open up a series of technical write ups, explaining the origin and exploitation process of all the CSRSS issues just fixed. Apart from five high-impact vulnerabilities, publically announced by Microsoft, I will also present two Denial of Service bugs, which can be used to generate an unhandled Access Violation exception, resulting in the CSRSS crash and a Blue Screen of Death. A complete list of the flaws to be discussed, together with their root cause is shown below:

Read more

Once upon a time, an interesting software vulnerability vector called DLL Hijacking became very popular, thanks to a Slovenian security research outfit – ACROS Security, as well as HD Moore and his DLL Hijacking Audit Kit. In short, the vulnerability class allowed an attacker to execute arbitrary code in the context of an application, which had been used to open an associated file from a remote share. The root cause of its existence was a combination of the three, following facts:

1. When opening a file from a remote share (such as WebDAV), the application’s Current Working Directory is set to the remote share path,
2. Using the LoadLibrary API with a relative path results in following a (Safe) Dynamic-Link Library Search Order. When the specified library cannot be found in the program’s directory and system folders, it is loaded from the CWD,
3. Some (flawed) applications try to load non-existent modules by their names (and react accordingly, if the DLL is not found).

The first two points have been well-documented in the MSDN Library, while the latter one was quite a typical Windows developers’ attitude, until the vulnerability class drew so much public attention. In this post, I would like to describe an idea, which I (together with gyn) had long before the DLL Hijacking hype. It is actually the very opposite of the previous concept – this time, our interest is primarily focused around static Portable Executable imports (rather than dynamic ones), and complex paths, instead of straight-forward library names (e.g. dx9draw.dll). The concept was than developed (and implemented, in the form of a straight-forward SMB server) by Gynvael Coldwind, which I would like to thank here.

Read more

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