sla-cker / google-security-research

Automatically exported from code.google.com/p/google-security-research
0 stars 0 forks source link

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

Closed GoogleCodeExporter closed 9 years ago

GoogleCodeExporter commented 9 years ago
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.

Original issue reported on code.google.com by mattt...@google.com on 10 Jul 2015 at 2:36

Attachments:

GoogleCodeExporter commented 9 years ago
Assigned MSRC case id 30628

Original comment by mattt...@google.com on 10 Jul 2015 at 7:40

GoogleCodeExporter commented 9 years ago
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/P
IC/PIC.c

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

Original comment by mattt...@google.com on 21 Jul 2015 at 9:27

GoogleCodeExporter commented 9 years ago

Original comment by cev...@google.com on 23 Jul 2015 at 3:58

GoogleCodeExporter commented 9 years ago
Deadline exceeded -- automatically derestricting

Original comment by haw...@google.com on 31 Jul 2015 at 5:00

GoogleCodeExporter commented 9 years ago
Fixed in https://technet.microsoft.com/library/security/MS15-080.

Original comment by mjurc...@google.com on 11 Aug 2015 at 8:56

GoogleCodeExporter commented 9 years ago

Original comment by mjurc...@google.com on 12 Aug 2015 at 12:14