New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.

Issue 480 link

Starred by 2 users

Issue metadata

Status: Fixed
Owner:
Email to this user bounced
Closed: Aug 2015
Cc:



Sign in to add a comment

Kernel-mode ASLR leak via uninitialized memory returned to usermode by NtGdiGetTextMetrics

Reported by matttait@google.com, Jul 10 2015

Issue description

A Kernel-mode ASLR leak exists in the Windows Text Metrics measurement subsystem due to the kernel returning uninitialized kernel pool information to usermode via the "NtGdiGetTextMetrics". This method can be used to reliably leak kernel mode pointers to both the kernel pool and kernel mode code.

The vulnerability exists due to the fact the Text Metrics subsystem deliberately tries to cache two distinct types of information: A TEXTMETRICW structure, and a TMDIFF structure, both of which are constructed on demand via different routes. The NtGdiGetTextMetrics will correctly construct both if neither are available, however if the TEXTMETRICW structure is available and the TMDIFF structure is not, the kernel will return the result containing uninitialized data where the TMDIFF structure would normally appear.

Triggering the vulnerability requires asking a valid device context (DC) to load a logical font (LFONT) object that has not previously been realized, and then requesting the object's TEXTMETRICW and structure via NtGdiGetTextMetricsW. This causes the LFONT object to be realized on demand, constructing and loading the corresponding RFONT, and caching the font's TEXTMETRICW information but not its TMDIFF information. NtGdiGetTextMetricsW then returns the generated TEXTMETRICW and the uninitialized TMDIFF structure to the caller.

Because of the way the RFONT's cached object is allocated, this reliably leaks a kernel-mode code pointer. However, because Win32k aggressively caches realized font (RFONT) objects associated with a logical font, it is sometimes necessary to construct multiple RFONTs from a single LFONT to ensure that a value is leaked.

The vulnerability gives local attackers the ability to de-ASLR the kernel from any permission level, and could be used to stabilize a local kernel-mode read/write vulnerability as part of a user-to-kernel privilege escalation.

This vulnerability affects Windows 7, Windows 8, 8.1 and Windows 10. The proof of concept provided targets only 64-bit editions of Windows, however 32-bit versions of Windows are also affected.
 
main.c
1.2 KB Download

Comment 1 by matttait@google.com, Jul 10 2015

Assigned MSRC case id 30628

Comment 2 by matttait@google.com, Jul 21 2015

This vulnerability was also discovered independently by HackingTeam (or one of their suppliers) https://github.com/vlad902/hacking-team-windows-kernel-lpe/blob/master/exploit/PIC/PIC.c

As per Google's vulnerability disclosure guidelines for exploits being exploited "in the wild", I'm reducing the deadline to 7 days.

Comment 3 by cevans@google.com, Jul 23 2015

Labels: -Deadline-90 Deadline-7
Project Member

Comment 4 by hawkes@google.com, Jul 31 2015

Labels: -Restrict-View-Commit
Deadline exceeded -- automatically derestricting
Project Member

Comment 5 by mjurczyk@google.com, Aug 11 2015

Labels: CVE-2015-2433
Status: Fixed
Fixed in https://technet.microsoft.com/library/security/MS15-080.
Project Member

Comment 6 by mjurczyk@google.com, Aug 12 2015

Labels: Fixed-11-Aug-2015 MSRC-30628

Sign in to add a comment