Month: July 2011

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