CVE-2016-0168 : Detail

CVE-2016-0168

6.5
/
Medium
A01-Broken Access Control
91.95%V3
Network
2016-05-10
23h00 +00:00
2018-10-12
17h57 +00:00
CVE.org
NVD
Notifications for a CVE
Stay informed of any changes for a specific CVE.
Notifications manage

CVE Descriptions

GDI in Microsoft Windows Vista SP2, Windows Server 2008 SP2 and R2 SP1, Windows 7 SP1, Windows 8.1, Windows Server 2012 Gold and R2, Windows RT 8.1, and Windows 10 Gold and 1511 allows remote attackers to obtain sensitive information via a crafted document, aka "Windows Graphics Component Information Disclosure Vulnerability," a different vulnerability than CVE-2016-0169.

CVE Informations

Related Weaknesses

CWE-ID Weakness Name Source
CWE-200 Exposure of Sensitive Information to an Unauthorized Actor
The product exposes sensitive information to an actor that is not explicitly authorized to have access to that information.

Metrics

Metrics Score Severity CVSS Vector Source
V3.0 6.5 MEDIUM CVSS:3.0/AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:N/A:N

Base: Exploitabilty Metrics

The Exploitability metrics reflect the characteristics of the thing that is vulnerable, which we refer to formally as the vulnerable component.

Attack Vector

This metric reflects the context by which vulnerability exploitation is possible.

Network

A vulnerability exploitable with network access means the vulnerable component is bound to the network stack and the attacker's path is through OSI layer 3 (the network layer). Such a vulnerability is often termed 'remotely exploitable' and can be thought of as an attack being exploitable one or more network hops away (e.g. across layer 3 boundaries from routers).

Attack Complexity

This metric describes the conditions beyond the attacker's control that must exist in order to exploit the vulnerability.

Low

Specialized access conditions or extenuating circumstances do not exist. An attacker can expect repeatable success against the vulnerable component.

Privileges Required

This metric describes the level of privileges an attacker must possess before successfully exploiting the vulnerability.

None

The attacker is unauthorized prior to attack, and therefore does not require any access to settings or files to carry out an attack.

User Interaction

This metric captures the requirement for a user, other than the attacker, to participate in the successful compromise of the vulnerable component.

Required

Successful exploitation of this vulnerability requires a user to take some action before the vulnerability can be exploited. For example, a successful exploit may only be possible during the installation of an application by a system administrator.

Base: Scope Metrics

An important property captured by CVSS v3.0 is the ability for a vulnerability in one software component to impact resources beyond its means, or privileges.

Scope

Formally, Scope refers to the collection of privileges defined by a computing authority (e.g. an application, an operating system, or a sandbox environment) when granting access to computing resources (e.g. files, CPU, memory, etc). These privileges are assigned based on some method of identification and authorization. In some cases, the authorization may be simple or loosely controlled based upon predefined rules or standards. For example, in the case of Ethernet traffic sent to a network switch, the switch accepts traffic that arrives on its ports and is an authority that controls the traffic flow to other switch ports.

Unchanged

An exploited vulnerability can only affect resources managed by the same authority. In this case the vulnerable component and the impacted component are the same.

Base: Impact Metrics

The Impact metrics refer to the properties of the impacted component.

Confidentiality Impact

This metric measures the impact to the confidentiality of the information resources managed by a software component due to a successfully exploited vulnerability.

High

There is total loss of confidentiality, resulting in all resources within the impacted component being divulged to the attacker. Alternatively, access to only some restricted information is obtained, but the disclosed information presents a direct, serious impact. For example, an attacker steals the administrator's password, or private encryption keys of a web server.

Integrity Impact

This metric measures the impact to integrity of a successfully exploited vulnerability. Integrity refers to the trustworthiness and veracity of information.

None

There is no loss of integrity within the impacted component.

Availability Impact

This metric measures the impact to the availability of the impacted component resulting from a successfully exploited vulnerability.

None

There is no impact to availability within the impacted component.

Temporal Metrics

The Temporal metrics measure the current state of exploit techniques or code availability, the existence of any patches or workarounds, or the confidence that one has in the description of a vulnerability.

Environmental Metrics

 [email protected]
V2 4.3 AV:N/AC:M/Au:N/C:P/I:N/A:N [email protected]

EPSS

EPSS is a scoring model that predicts the likelihood of a vulnerability being exploited.

EPSS Score

The EPSS model produces a probability score between 0 and 1 (0 and 100%). The higher the score, the greater the probability that a vulnerability will be exploited.

EPSS Percentile

The percentile is used to rank CVE according to their EPSS score. For example, a CVE in the 95th percentile according to its EPSS score is more likely to be exploited than 95% of other CVE. Thus, the percentile is used to compare the EPSS score of a CVE with that of other CVE.
EPSS First.org

Exploit information

Exploit Database EDB-ID : 39832

Publication date : 2016-05-16 22h00 +00:00
Author : Google Security Research
EDB Verified : Yes

Source: https://bugs.chromium.org/p/project-zero/issues/detail?id=722 There are multiple programming errors in the implementation of the CREATECOLORSPACEW record in EMF files, as found in the user-mode gdi32.dll system library. The worst of them may lead to reading beyond allocated heap-based buffers, leading to a crash or potential disclosure of the library client's memory (e.g. Internet Explorer's). Another bug may also lead to disclosure of information regarding the existence of arbitrary files in the file system. Each of the discovered bugs is briefly described below. The analysis was based on a 32-bit gdi32.dll file found in the C:\Windows\SysWOW64 directory on a fully patched Windows 7 operating system. -------------------------------------------------------------------------------- - Out-of-bounds read of EMR_CREATECOLORSPACEW.cbData in MRCREATECOLORSPACEW::bCheckRecord -------------------------------------------------------------------------------- The MRCREATECOLORSPACEW::bCheckRecord() function starts off by checking if the length of the record is greater or equal than 0x50 (80): --- cut --- .text:7DB01AEF mov eax, [esi+4] .text:7DB01AF2 cmp eax, 50h .text:7DB01AF5 jb short loc_7DB01B1E --- cut --- and then immediately proceeds to reading the .cbData field at offset 0x25c (604): --- cut --- .text:7DB01AF7 mov ecx, [esi+25Ch] --- cut --- Since the record is not guaranteed to be large enough to hold the value at +0x25c, the instruction shown above can read beyond the allocated buffer. The attached oob.emf file illustrates this issue. -------------------------------------------------------------------------------- - Integer overflow when checking EMR_CREATECOLORSPACEW.cbData in MRCREATECOLORSPACEW::bCheckRecord -------------------------------------------------------------------------------- Furthermore, the value obtained from offset +0x25c is also used to verify the record length, as part of the (record.length <= ((record->cbData + 0x263) & 0xfffffffc)) expression: --- cut --- .text:7DB01AF7 mov ecx, [esi+25Ch] .text:7DB01AFD add ecx, 263h .text:7DB01B03 and ecx, 0FFFFFFFCh .text:7DB01B06 cmp eax, ecx .text:7DB01B08 ja short loc_7DB01B1E --- cut --- Since there is no overflow check in the arithmetic operation, if the cbData field is sufficiently large, it may overflow the 32-bit type. It is not clear, however, why the record length is required to be *smaller* than the structure's field in the first place (intuitively, it should be larger). Whether this is a mistake or not doesn't really seem to matter, as the optional color space data is not used further in the MRCREATECOLORSPACEW::bPlay() function anyway. -------------------------------------------------------------------------------- - Out-of-bounds read in CreateColorSpaceW -------------------------------------------------------------------------------- The LOGCOLORSPACEW structure passed to CreateColorSpaceW() by MRCREATECOLORSPACEW::bPlay() is assumed to be at least 0x24c (588) bytes long. However, as we've seen before, the record is only guaranteed to be at least 80 bytes long. As a result, in case of a specially crafted small record, the CreateColorSpaceW() function could operate on data well beyond the record's buffer. The memory from outside the buffer could then be potentially recovered by reading back pixels using the HTML5 canvas API, and deriving the uninitialized values of the LOGCOLORSPACEW structure. The attached oob.emf file also illustrates this issue (in terms of passing OOB heap data to CreateColorSpaceW), provided that the out-of-bounds .cbData check passes successfully in MRCREATECOLORSPACEW::bCheckRecord(), but this is very likely as there are only a few specific values of .cbData which could cause it to fail. -------------------------------------------------------------------------------- - File existence information disclosure in CreateColorSpaceW -------------------------------------------------------------------------------- This is perhaps the most interesting bug found in the handling of the CREATECOLORSPACEW / CREATECOLORSPACE EMF records. After being passed a specially crafted LOGCOLORSPACEW structure, the CreateColorSpaceW() function builds a file path based on the LOGCOLORSPACEW.lcsFilename field, using the BuildIcmProfilePath() routine: --- cut --- .text:7DAEF12E push 104h ; cchDest .text:7DAEF133 lea eax, [ebp+FileName] .text:7DAEF139 push eax ; pszDest .text:7DAEF13A push ebx ; pszSrc .text:7DAEF13B call _BuildIcmProfilePath@12 ; BuildIcmProfilePath(x,x,x) --- cut --- While paths starting with "\\" are forbidden (limiting access to remote or internal system resources), all other paths, including absolute ones, are allowed. The function then attempts to open the file in order to make sure that it exists, and if this succeeds, the resulting handle is immediately closed: --- cut --- hFile = CreateFileW(&FileName, GENERIC_READ, FILE_SHARE_READ, 0, OPEN_EXISTING, FILE_ATTRIBUTE_NORMAL, 0); if ( hFile == INVALID_HANDLE_VALUE ) { GdiSetLastError(2016); return 0; } CloseHandle(hFile); --- cut --- Only if the file exists, the code proceeds to invoking the NtGdiCreateColorSpace system call, which creates a Color Space GDI object based on the input structure. This behavior can be used to disclose information regarding the existence of specific (attacker-chosen) files in the file system through applications (GDI client) which enable the propagation of rendered image's pixels back to the attacker, such as the Internet Explorer web browser. The most intuitive way of propagating the result of the CreateFileW() call would be to insert a crafted CREATECOLORSPACEW record in the EMF file, followed by actual drawing primitives. If the color space creation failed (due to a non-existent file), the remainder of the image wouldn't get parsed and displayed, which could then be easily detected in JavaScript. Unfortunately, the idea is blocked in practice by the fact that even if any of the particular EMF record handlers fail, the gdi32!bInternalPlayEMF function only sets a local "status" variable to FALSE, and continues handling subsequent records nevertheless. The status variable is then returned to the caller, but in case of Internet Explorer, it is immediately discarded in the mshtml!CImgTaskEmf::Decode function: --- cut --- .text:64162B49 call ds:__imp__PlayEnhMetaFile@12 ; PlayEnhMetaFile(x,x,x) .text:64162B4F or dword ptr [ebx+7Ch], 0FFFFFFFFh .text:64162B53 lea eax, [esp+4C8h+var_49C] --- cut --- As a result, the return value of the CreateFileW() call is completely lost and cannot be inferred directly. Instead, a different, indirect approach must be applied, based on the side effects of the CREATECOLORSPACE record handling. When a color space is created, a corresponding GDI handle is created for the process and stored in the EMF handle table. Considering that the default per-process GDI handle quota is set at 10'000, it is feasible to exhaust it by creating an excessive number of objects. The exploit image could be crafted as follows: 1. EMR_HEADER 2. EMR_CREATECOLORSPACE (containing the file system path to examine) 3. EMR_CREATECOLORSPACE . . . 10001. EMR_CREATECOLORSPACE 10002. EMR_CREATEBRUSHINDIRECT 10003. EMR_SELECTOBJECT 10004. EMR_POLYGON 10005. EMR_EOF If the file path specified in the 10000 EMR_CREATECOLORSPACE records exists, the GDI handle space will be filled up, causing the brush creation in step #10002 to fail, and thus the polygon drawn in step #10004 to not have any color. On the other hand, if the file doesn't exist, none of the color spaces will be created, allowing the creation of a brush, which will then be used to draw a colored polygon. When such an image is loaded over a HTML5 canvas, JavaScript can then read the pixels back using canvas.getImageData(), which is synonymous to the existence (or lack) of the chosen file. The attached notepad_leak.emf file illustrates the bug. When it is loaded in Internet Explorer in its original form (checking for the existence of C:\Windows\notepad.exe), the edges of the polygon (rectangle) are visible, but there is no fill color. The IE renderer process should have 10'000 GDI handles opened, which can be verified with Task Manager, Process Explorer, or e.g. by trying to use the context menu within the website's window area (it will misbehave due to lack of available GDI handles). When all instances of the "C:\Windows\notepad.exe" string are replaced with a non-existent (but same length, to preserve metadata correctness) path in the POC file, Internet Explorer will correctly display the green polygon fill, and won't hold an excessive number of handles. James Forshaw noted that the check in BuildIcmProfilePath() against the "\\" prefix (or, in fact, against both '\' and '/' in the first two characters) is not effective in preventing access to UNC paths, as there is an equivalent "\??\" prefix (tested on Windows 7+), which can be used for the same purpose. This observation further elevates the severity of the "file existence information disclosure" bug, as it is now possible to reference nearly all resources the CreateFile() API is capable of opening. Some example risks are as follows: 1) By referencing a file on an attacker-controlled server, it is possible to track users opening the crafted EMF file (within any application using GDI, not just Internet Explorer). 2) Disclosure of the existence of files residing in network shares available to the currently logged in user. 3) James suggested it might also facilitate stealing NTLM hashes. Another note is that the gdi32.dll SETICMPROFILEA and SETICMPROFILEW record handlers also reference the BuildIcmProfilePath() function, so it might be worth doing some light variant analysis to check if any of the path-related problems described in this bug affect those records too. Proof of Concept: https://gitlab.com/exploit-database/exploitdb-bin-sploits/-/raw/main/bin-sploits/39832.zip

Products Mentioned

Configuraton 0

Microsoft>>Windows_10 >> Version *

Microsoft>>Windows_10 >> Version 1511

Microsoft>>Windows_7 >> Version *

Microsoft>>Windows_8.1 >> Version *

Microsoft>>Windows_rt_8.1 >> Version *

Microsoft>>Windows_server_2008 >> Version *

Microsoft>>Windows_server_2008 >> Version r2

Microsoft>>Windows_server_2012 >> Version *

Microsoft>>Windows_server_2012 >> Version r2

Microsoft>>Windows_vista >> Version *

References

http://www.securitytracker.com/id/1035823
Tags : vdb-entry, x_refsource_SECTRACK
http://www.securityfocus.com/bid/89862
Tags : vdb-entry, x_refsource_BID