Mailing List Archive

CORE-2011-1123: Windows Kernel ReadLayoutFile Heap Overflow
Hash: SHA1

Core Security - Corelabs Advisory

Windows Kernel ReadLayoutFile Heap Overflow

1. *Advisory Information*

Title: Windows Kernel ReadLayoutFile Heap Overflow
Advisory ID: CORE-2011-1123
Advisory URL:
Date published: 2012-05-08
Date of last update: 2011-05-08
Vendors contacted: Microsoft
Release mode: Coordinated release

2. *Vulnerability Information*

Class: Heap-based Buffer Overflow [CWE-122]
Impact: Code execution
Remotely Exploitable: No
Locally Exploitable: Yes
CVE Name: CVE-2012-0181

3. *Vulnerability Description*

There is a bug in the ReadLayoutFile Windows Kernel function that can be
leveraged into a local privilege escalation exploit, potentially usable
in a client-side attack scenario or after a remote intrusion by other means.

This bug is similar to another bug used by a client-side exploit in Stuxnet.

4. *Vulnerable packages*

. Windows XP SP3.
. Windows Vista SP2.
. Windows 7 SP1.
. Windows Server 2003 SP2.
. Windows Server 2008 SP2.
. Other Windows versions might be vulnerable but were not tested.

5. *Vendor Information, Solutions and Workarounds*

Apply security patch MS12-034 [3].

6. *Credits*

This vulnerability was discovered and researched by Nicolás Economou
from Core Security Technologies. The publication of this advisory was
coordinated by Fernando Russ.

7. *Technical Description / Proof of Concept Code*

There is a bug in the 'ReadLayoutFile' Windows Kernel ('win32k.sys')
function that can be leveraged into a local privilege escalation
exploit, potentially usable in a client-side attack scenario, or after a
remote intrusion by other means.

Custom keyboard layouts are implemented using a .dll file exporting the
'KbdLayerDescriptor' function which, in theory, returns a pointer to a
structure of type 'KBDTABLES' that is stored in the '.DATA' sections of
the PE file. The 'NtUserLoadKeyboardLayoutEx' is a private function used
by 'LoadKeyboardLayout' [2] to load a custom keyboard layout, as
arguments 'NtUserLoadKeyboardLayoutEx' uses an open file handle pointing
to a keyboard layout library. When the function
'NtUserLoadKeyboardLayoutEx' is correctly called the PE file referenced
by its arguments is mapped in kernel space.

The bug is due to a memory corruption: a double word can be overwritten
in a position relative to the base of the allocated memory in kernel
space. We have to distinguish two different scenarios for exploiting
this vulnerability:

For Windows XP,
. There is no check for the path from where the keyboard layout will
be loaded. (So, we can craft a file and use it as keyboard layout
without having write permission on \Windows\System32)
. There is no bound check for the value used to index the '.DATA'
section of the keyboard layout .dll where the actual where the actual
layout descriptor table is stored. (So, we can reference spurious memory

For other vulnerable Windows Versions,
. The file handle used to load the keyboard layout must refer to a
file located in \Windows\System32.
. The value used to index the '.DATA' section of the keyboard layout
is incorrectly bound checked.

We can confirm reliable exploitation for the following Microsoft Windows

. Windows XP SP3
. Windows Server 2003 SP2
. Windows Server 2008 SP2

8. *Report Timeline*

. 2011-11-23:
Core Security Technologies notifies MSRC of the vulnerability, including
technical details and a PoC that crashes Windows XP SP3.

. 2011-11-23:
Vendor acknowledges the receipt of the information. Vendor warns Core
Security Technologies that it may take longer than normal for a
technical review of the bug because of the Thanksgiving holiday.

. 2011-11-24:
Core acknowledges the aforementioned possible delay and wishes MSRC a
happy Thanksgiving.

. 2011-11-25:
MSRC opens case number "MSRC 12000gd" for report tracking.

. 2011-11-28:
MSRC mentions over an unencrypted communication channel that they are
currently investigating the issue, and that they'll let Core Security
Technologies know of their findings when the investigation is complete.

. 2011-11-29:
Core Security Technologies acknowledges the previous e-mail.

. 2011-12-08:
MSRC contacts Core Security Technologies for a quick update, informing
that they were able to reproduce the crash and that it is indeed very
similar to bug publicly exploited at [1]. MSRC informs that they are
currently discussing the next steps they will take with Windows Product

. 2012-01-09:
Ivan Arce, current CTO and founder of the Core Advisories Team, leaves
Core after 15 years. Thanks Wari!

. 2012-01-17:
MSRC notifies that the release of a fix was scheduled for March 2012.

. 2012-01-18:
Core acknowledges the previous update and notifies that Nicolas Economou
has further analyzed the crash (publicly available in exploit-db) and
concluded it is indeed a different issue. Core offers to compile
Nicolas' findings into a private technical report.

. 2012-01-18:
MSRC validates Nicolas' findings stating the two issues are separate,
even though they share a same code area.

. 2012-03-09:
Core asks if the March publication date still stands.

. 2012-03-12:
MSRC notifies that, due to some late findings about app-compat concerns,
they will need more time to issue the patch. MSRC asks to re-schedule
the advisory publication to May 8th.

. 2012-03-09:
Core re-schedules the advisory publication to May 8th.

. 2012-04-01:
Pedro Varangot leaves the Core Advisories Team. Thanks Peter and good
luck with your new challenges.

. 2012-04-02:
Core asks for additional information regarding the actual vulnerable
Windows' versions and specific workarounds for this vulnerability.

. 2012-04-03:
MSRC notifies that the actual vulnerable systems are Windows XP/2003 as
Elevation of Privileges and Windows Vista/2008 as Denial of Service.
MSRC also notifies that no workaround has been identified for this

. 2012-05-08:
The advisory CORE-2011-1123 is published.

9. *References*



10. *About CoreLabs*

CoreLabs, the research center of Core Security Technologies, is charged
with anticipating the future needs and requirements for information
security technologies. We conduct our research in several important
areas of computer security including system vulnerabilities, cyber
attack planning and simulation, source code auditing, and cryptography.
Our results include problem formalization, identification of
vulnerabilities, novel solutions and prototypes for new technologies.
CoreLabs regularly publishes security advisories, technical papers,
project information and shared software tools for public use at:

11. *About Core Security Technologies*

Core Security Technologies enables organizations to get ahead of threats
with security test and measurement solutions that continuously identify
and demonstrate real-world exposures to their most critical assets. Our
customers can gain real visibility into their security standing, real
validation of their security controls, and real metrics to more
effectively secure their organizations.
Core Security's software solutions build on over a decade of trusted
research and leading-edge threat expertise from the company's Security
Consulting Services, CoreLabs and Engineering groups. Core Security
Technologies can be reached at +1 (617) 399-6980 or on the Web at:

12. *Disclaimer*

The contents of this advisory are copyright (c) 2012 Core Security
Technologies and (c) 2012 CoreLabs, and are licensed under a Creative
Commons Attribution Non-Commercial Share-Alike 3.0 (United States)

13. *PGP/GPG Keys*

This advisory has been signed with the GPG key of Core Security
Technologies advisories team, which is available for download at
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla -


Full-Disclosure - We believe in it.
Hosted and sponsored by Secunia -