English
Français
Light
Dark
System

Alert System

Stay informed at all times
Create an account Open a free account Login Manage your alerts

CVE-2017-0058 : Detail

CVE-2017-0058

4.7
/
MEDIUM
A01-Broken Access Control
0.14%V3
Local
2017-04-12 12:00 +00:00
2017-08-15 07:57 +00:00
CVE.org
NVD

Alert for a CVE

Stay informed of any changes for a specific CVE.
Alert management

Descriptions

A Win32k information disclosure vulnerability exists in Microsoft Windows when the win32k component improperly provides kernel information. An attacker who successfully exploited the vulnerability could obtain information to further compromise the user's system, aka "Win32k Information Disclosure Vulnerability."

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

Metric Score Severity CVSS Vector Source
V3.0 4.7 MEDIUM CVSS:3.0/AV:L/AC:H/PR:L/UI:N/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.

Local

A vulnerability exploitable with Local access means that the vulnerable component is not bound to the network stack, and the attacker's path is via read/write/execute capabilities. In some cases, the attacker may be logged in locally in order to exploit the vulnerability, otherwise, she may rely on User Interaction to execute a malicious file.

Attack Complexity

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

High

A successful attack depends on conditions beyond the attacker's control. That is, a successful attack cannot be accomplished at will, but requires the attacker to invest in some measurable amount of effort in preparation or execution against the vulnerable component before a successful attack can be expected.

Privileges Required

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

Low

The attacker is authorized with (i.e. requires) privileges that provide basic user capabilities that could normally affect only settings and files owned by a user. Alternatively, an attacker with Low privileges may have the ability to cause an impact only to non-sensitive resources.

User Interaction

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

None

The vulnerable system can be exploited without interaction from any user.

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

 nvd@nist.gov
V2 1.9 AV:L/AC:M/Au:N/C:P/I:N/A:N nvd@nist.gov

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 : 41879

Publication date : 2017-04-12 22:00 +00:00
Author : Google Security Research
EDB Verified : Yes

Source: https://bugs.chromium.org/p/project-zero/issues/detail?id=1078 We have discovered two bugs in the implementation of the win32k!NtGdiGetDIBitsInternal system call, which is a part of the graphic subsystem in all modern versions of Windows. The issues can potentially lead to kernel pool memory disclosure (bug #1) or denial of service (bug #1 and #2). Under certain circumstances, memory corruption could also be possible. ----------[ Double-fetch while handling the BITMAPINFOHEADER structure ]---------- At the beginning of the win32k!NtGdiGetDIBitsInternal system call handler, the code references the BITMAPINFOHEADER structure (and specifically its .biSize field) several times, in order to correctly calculate its size and capture it into kernel-mode memory. A pseudo-code representation of the relevant code is shown below, where "bmi" is a user-controlled address: --- cut --- ProbeForRead(bmi, 4, 1); ProbeForWrite(bmi, bmi->biSize, 1); <------------ Fetch #1 header_size = GreGetBitmapSize(bmi); <----------- Fetch #2 captured_bmi = Alloc(header_size); ProbeForRead(bmi, header_size, 1); memcpy(captured_bmi, bmi, header_size); <-------- Fetch #3 new_header_size = GreGetBitmapSize(bmi); if (header_size != new_header_size) { // Bail out. } // Process the data further. --- cut --- In the snippet above, we can see that the user-mode "bmi" buffer is accessed thrice: when accessing the biSize field, in the GreGetBitmapSize() call, and in the final memcpy() call. While this is clearly a multi-fetch condition, it is mostly harmless: since there is a ProbeForRead() call for "bmi", it must be a user-mode address, so bypassing the subsequent ProbeForWrite() call by setting bmi->biSize to 0 doesn't change much. Furthermore, since the two results of the GreGetBitmapSize() calls are eventually compared, introducing any inconsistencies in between them is instantly detected. As far as we are concerned, the only invalid outcome of the behavior could be read access to out-of-bounds pool memory in the second GreGetBitmapSize() call. This is achieved in the following way: 1. Invoke NtGdiGetDIBitsInternal with a structure having the biSize field set to 12 (sizeof(BITMAPCOREHEADER)). 2. The first call to GreGetBitmapSize() now returns 12 or a similar small value. 3. This number of bytes is allocated for the header buffer. 4. (In a second thread) Change the value of the biSize field to 40 (sizeof(BITMAPINFOHEADER)) before the memcpy() call. 5. memcpy() copies the small structure (with incorrectly large biSize) into the pool allocation. 6. When called again, the GreGetBitmapSize() function assumes that the biSize field is set adequately to the size of the corresponding memory area (untrue), and attempts to access structure fields at offsets greater than 12. The bug is easiest to reproduce with Special Pools enabled for win32k.sys, as the invalid memory read will then be reliably detected and will yield a system bugcheck. An excerpt from a kernel crash log triggered using the bug in question is shown below: --- cut --- DRIVER_PAGE_FAULT_BEYOND_END_OF_ALLOCATION (d6) N bytes of memory was allocated and more than N bytes are being referenced. This cannot be protected by try-except. When possible, the guilty driver's name (Unicode string) is printed on the bugcheck screen and saved in KiBugCheckDriver. Arguments: Arg1: fe3ff008, memory referenced Arg2: 00000000, value 0 = read operation, 1 = write operation Arg3: 943587f1, if non-zero, the address which referenced memory. Arg4: 00000000, (reserved) Debugging Details: ------------------ [...] TRAP_FRAME: 92341b1c -- (.trap 0xffffffff92341b1c) ErrCode = 00000000 eax=fe3fefe8 ebx=00000000 ecx=00000000 edx=00000028 esi=00000004 edi=01240000 eip=943587f1 esp=92341b90 ebp=92341b98 iopl=0 nv up ei pl zr na pe nc cs=0008 ss=0010 ds=0023 es=0023 fs=0030 gs=0000 efl=00010246 win32k!GreGetBitmapSize+0x34: 943587f1 8b7820 mov edi,dword ptr [eax+20h] ds:0023:fe3ff008=???????? Resetting default scope LAST_CONTROL_TRANSFER: from 816f9dff to 816959d8 STACK_TEXT: 9234166c 816f9dff 00000003 09441320 00000065 nt!RtlpBreakWithStatusInstruction 923416bc 816fa8fd 00000003 00000000 00000002 nt!KiBugCheckDebugBreak+0x1c 92341a80 816a899d 00000050 fe3ff008 00000000 nt!KeBugCheck2+0x68b 92341b04 8165af98 00000000 fe3ff008 00000000 nt!MmAccessFault+0x104 92341b04 943587f1 00000000 fe3ff008 00000000 nt!KiTrap0E+0xdc 92341b98 9434383e fe3fefe8 00000000 067f9cd5 win32k!GreGetBitmapSize+0x34 92341c08 81657db6 00000000 00000001 00000000 win32k!NtGdiGetDIBitsInternal+0x17f 92341c08 011d09e1 00000000 00000001 00000000 nt!KiSystemServicePostCall [...] --- cut --- The out-of-bounds data read by GreGetBitmapSize() could then be extracted back to user-mode to some degree, which could help disclose sensitive data or defeat certain kernel security mitigations (such as kASLR). Attached is a PoC program for Windows 7 32-bit (double_fetch_oob_read.cpp). ----------[ Unhandled out-of-bounds write to user-mode memory when requesting RLE-compressed bitmaps ]---------- The 5th parameter of the NtGdiGetDIBitsInternal syscall is a pointer to an output buffer where the bitmap data should be written to. The length of the buffer is specified in the 8th parameter, and can be optionally 0. The logic of sanitizing and locking the memory area is shown below ("Buffer" is the 5th argument and "Length" is the 8th). --- cut --- if (Length != 0 || (Length = GreGetBitmapSize(bmi)) != 0) { ProbeForWrite(Buffer, Length, 4); MmSecureVirtualMemory(Buffer, Length, PAGE_READWRITE); } --- cut --- We can see that if the "Length" argument is non-zero, it is prioritized over the result of GreGetBitmapSize() in specifying how many bytes of the user-mode output buffer should be locked in memory as readable/writeable. Since the two calls above are supposed to guarantee that the required user-mode memory region will be accessible until it is unlocked, the call to the GreGetDIBitsInternal() function which actually fills the buffer with data is not guarded with a try/except block. However, if we look into GreGetDIBitsInternal() and further into GreGetDIBitsInternalWorker(), we can see that if a RLE-compressed bitmap is requested by the user (as indicated by bmi.biCompression set to BI_RLE[4,8]), the internal EncodeRLE4() and EncodeRLE8() routines are responsible for writing the output data. The legal size of the buffer is passed through the functions' 5th parameter (last one), and is always set to bmi.biSizeImage. This creates a discrepancy: a different number of bytes is ensured to be present in memory (Length), and a different number can be actually written to it (bmi.biSizeImage). Due to the lack of exception handling in this code area, the resulting exception causes a system-wide bugcheck: --- cut --- KERNEL_MODE_EXCEPTION_NOT_HANDLED (8e) This is a very common bugcheck. Usually the exception address pinpoints the driver/function that caused the problem. Always note this address as well as the link date of the driver/image that contains this address. Some common problems are exception code 0x80000003. This means a hard coded breakpoint or assertion was hit, but this system was booted /NODEBUG. This is not supposed to happen as developers should never have hardcoded breakpoints in retail code, but ... If this happens, make sure a debugger gets connected, and the system is booted /DEBUG. This will let us see why this breakpoint is happening. Arguments: Arg1: c0000005, The exception code that was not handled Arg2: 9461564b, The address that the exception occurred at Arg3: 9d0539a0, Trap Frame Arg4: 00000000 Debugging Details: ------------------ [...] TRAP_FRAME: 9d0539a0 -- (.trap 0xffffffff9d0539a0) ErrCode = 00000002 eax=00291002 ebx=00291000 ecx=00000004 edx=fe9bb1c1 esi=00000064 edi=fe9bb15c eip=9461564b esp=9d053a14 ebp=9d053a40 iopl=0 nv up ei ng nz ac pe cy cs=0008 ss=0010 ds=0023 es=0023 fs=0030 gs=0000 efl=00010297 win32k!EncodeRLE8+0x1ac: 9461564b c60300 mov byte ptr [ebx],0 ds:0023:00291000=?? Resetting default scope [...] STACK_TEXT: 9d052f5c 8172adff 00000003 17305ce1 00000065 nt!RtlpBreakWithStatusInstruction 9d052fac 8172b8fd 00000003 9d0533b0 00000000 nt!KiBugCheckDebugBreak+0x1c 9d053370 8172ac9c 0000008e c0000005 9461564b nt!KeBugCheck2+0x68b 9d053394 817002f7 0000008e c0000005 9461564b nt!KeBugCheckEx+0x1e 9d053930 81689996 9d05394c 00000000 9d0539a0 nt!KiDispatchException+0x1ac 9d053998 8168994a 9d053a40 9461564b badb0d00 nt!CommonDispatchException+0x4a 9d053a40 944caea9 fe9bb1c1 ff290ffc 00000064 nt!KiExceptionExit+0x192 9d053b04 944e8b09 00000028 9d053b5c 9d053b74 win32k!GreGetDIBitsInternalWorker+0x73e 9d053b7c 944d390f 0c0101fb 1f050140 00000000 win32k!GreGetDIBitsInternal+0x21b 9d053c08 81688db6 0c0101fb 1f050140 00000000 win32k!NtGdiGetDIBitsInternal+0x250 9d053c08 00135ba6 0c0101fb 1f050140 00000000 nt!KiSystemServicePostCall [...] --- cut --- While the size of the buffer passed to EncodeRLE[4,8] can be arbitrarily controlled through bmi.biSizeImage (32-bit field), it doesn't enable an attacker to corrupt kernel-mode memory, as the memory writing takes place sequentially from the beginning to the end of the buffer. Furthermore, since the code in NtGdiGetDIBitsInternal() makes sure that the buffer size passed to ProbeForWrite() is >= 1, its base address must reside in user space. As such, this appears to be a DoS issue only, if we haven't missed anything in our analysis. Attached is a PoC program for Windows 7 32-bit (usermode_oob_write.cpp), and a bitmap file necessary for the exploit to work (test.bmp). Proof of Concept: https://gitlab.com/exploit-database/exploitdb-bin-sploits/-/raw/main/bin-sploits/41879.zip

Products Mentioned

Configuraton 0

Microsoft>>Windows_10 >> Version *

Microsoft>>Windows_10 >> Version 1511

Microsoft>>Windows_10 >> Version 1607

Microsoft>>Windows_10 >> Version 1703

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_server_2016 >> Version *

Microsoft>>Windows_vista >> Version *

References

http://www.securityfocus.com/bid/97462
Tags : vdb-entry, x_refsource_BID
https://www.exploit-db.com/exploits/41879/
Tags : exploit, x_refsource_EXPLOIT-DB
http://www.securitytracker.com/id/1038239
Tags : vdb-entry, x_refsource_SECTRACK

More information
Click on the button to the left (OFF), to authorize the inscription of cookie improving the functionalities of the site. Click on the button to the left (Accept all), to unauthorize the inscription of cookie improving the functionalities of the site.