CVE-2017-0220 : Detail

CVE-2017-0220

4.7
/
Medium
A01-Broken Access Control
5%V4
Local
2017-05-12
12h00 +00:00
2017-08-12
07h57 +00:00
CVE.org
NVD
Notifications for a CVE
Stay informed of any changes for a specific CVE.
Notifications manage

CVE Descriptions

The Windows kernel in Windows Server 2008 SP2 and R2 SP1, Windows 7 SP1, and Windows Server 2012 Gold allows authenticated attackers to obtain sensitive information via a specially crafted document, aka "Windows Kernel Information Disclosure Vulnerability," a different vulnerability than CVE-2017-0175, CVE-2017-0258, and CVE-2017-0259.

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

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

Source: https://bugs.chromium.org/p/project-zero/issues/detail?id=1127 We have identified two related bugs in Windows kernel code responsible for implementing the bind() socket function, specifically in the afd!AfdBind and tcpip!TcpBindEndpoint routines. They both can lead to reading beyond the allocated pool-based buffer memory area, potentially allowing user-mode applications to disclose kernel-mode secrets. They can also be exploited to trigger a blue screen of death and therefore a Denial of Service condition. The details are explained below. ----------[ Double-fetch in afd!AfdBind ]---------- In the code of the afd!AfdBind function of the up-to-date afd.sys module (handler of the AFD_BIND IOCTL accessible from ring-3) on Windows 7 32-bit, we can find the following assembly code construct: --- cut --- PAGE:00024D71 push 0EC646641h ; Tag PAGE:00024D76 push [ebp+NumberOfBytes] ; NumberOfBytes PAGE:00024D79 push 10h ; PoolType PAGE:00024D7B call ds:__imp__ExAllocatePoolWithQuotaTag@12 [...] PAGE:00024DD2 lea edi, [eax+4] PAGE:00024DD5 push edi ; void * PAGE:00024DD6 push [ebp+P] ; void * PAGE:00024DD9 call ds:__imp__memmove <------------------- Fetch #1 PAGE:00024DDF add esp, 0Ch PAGE:00024DE2 movzx eax, word ptr [edi] <----------------- Fetch #2 PAGE:00024DE5 cmp ax, 22h PAGE:00024DE9 jb short loc_24E01 [...] PAGE:00024E01 PAGE:00024E01 loc_24E01: PAGE:00024E01 push eax PAGE:00024E02 call _SOCKADDR_SIZE@4 ; SOCKADDR_SIZE(x) PAGE:00024E07 movzx eax, al PAGE:00024E0A cmp [ebp+NumberOfBytes], eax PAGE:00024E0D jnb short loc_24E25 --- cut --- Which translates to the following pseudo-code: --- cut --- LPINPUTSTRUCT lpKernelStruct = ExAllocatePool(NumberOfBytes); memmove(lpKernelStruct, lpUserStruct, NumberOfBytes); <-------------------- Fetch #1 if (NumberOfBytes < SOCKADDR_SIZE(lpUserStruct->dwStructType)) { <--------- Fetch #2 // Bail out. } --- cut --- As can be seen, the first WORD of the input structure is fetched twice from a user-mode buffer: once during the memmove() call, and once when directly accessing it to pass its value as an argument to the SOCKADDR_SIZE function. The SOCKADDR_SIZE function is mostly just a wrapper around the constant sockaddr_size[] array, which has the following values: * indexes 0x00..0x01: 0x00 * index 0x02: 0x10 * indexes 0x03..0x16: 0x00 * index 0x17: 0x1C * indexes 0x16..0x21: 0x00 The double fetch makes it possible for the first WORD of the structure to have different values on each access from kernel-mode (through another thread concurrently flipping its bits). For example, it could have the valid value 2 or 0x17 at the time of the memmove(), but any other value at the time of the direct access. This would lead to comparing the input structure size with 0 (which is the corresponding entry in sockaddr_size[]), effectively nullifying the sanitization. Other code down the execution flow may then assume that the size of the buffer has been correctly verified, and access some fields at predefined offsets, which may be located outside of the allocated buffer, if the user specifies a very small size. In our case, the confused code is in tcpip!TcpBindEndpoint, which tries to copy an excessive number of bytes from a very small allocation. A crash log excerpt 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: 8c5ed000, memory referenced Arg2: 00000000, value 0 = read operation, 1 = write operation Arg3: 84c703fe, if non-zero, the address which referenced memory. Arg4: 00000000, (reserved) Debugging Details: ------------------ [...] TRAP_FRAME: 96647818 -- (.trap 0xffffffff96647818) ErrCode = 00000000 eax=9512d970 ebx=95051020 ecx=00000003 edx=00000000 esi=8c5ed000 edi=9505104c eip=84c703fe esp=9664788c ebp=96647898 iopl=0 nv up ei ng nz ac po cy cs=0008 ss=0010 ds=0023 es=0023 fs=0030 gs=0000 efl=00010293 tcpip!TcpBindEndpoint+0x51: 84c703fe f3a5 rep movs dword ptr es:[edi],dword ptr [esi] Resetting default scope LAST_CONTROL_TRANSFER: from 81722dff to 816be9d8 STACK_TEXT: 9664736c 81722dff 00000003 d1dfd5f3 00000065 nt!RtlpBreakWithStatusInstruction 966473bc 817238fd 00000003 00000000 00000004 nt!KiBugCheckDebugBreak+0x1c 96647780 816d199d 00000050 8c5ed000 00000000 nt!KeBugCheck2+0x68b 96647800 81683f98 00000000 8c5ed000 00000000 nt!MmAccessFault+0x104 96647800 84c703fe 00000000 8c5ed000 00000000 nt!KiTrap0E+0xdc 96647898 84c7039e 951769a0 8c2e3896 9512d970 tcpip!TcpBindEndpoint+0x51 966478b8 84c72900 951769a0 966479cc 00000000 tcpip!TcpIoControlEndpoint+0x199 966478cc 816ccbe5 9664795c d1dfdf7b 00000000 tcpip!TcpTlEndpointIoControlEndpointCalloutRoutine+0x8b 96647934 84c6d89e 84c72875 9664795c 00000000 nt!KeExpandKernelStackAndCalloutEx+0x132 9664796c 8c2e05ed 95176900 96647901 966479f8 tcpip!TcpTlEndpointIoControlEndpoint+0x67 966479a0 8c2e06aa 84c6d837 951769a0 966479cc afd!AfdTLIoControl+0x33 966479b8 8c2e3afa 8c53eef0 966479cc 9512d970 afd!AfdTLEndpointIoControl+0x1a 966479f8 8c2e388a 9512d970 8c53eef0 9512d970 afd!AfdTLBind+0x4b 96647a40 8c2d3eb8 9512d970 8c53eef0 00000000 afd!AfdTLBindSecurity+0x108 96647aac 8c2e02bc 85e81198 9512d970 96647ae0 afd!AfdBind+0x283 96647abc 8197d4d9 8bc0edd0 9512d970 85e81198 afd!AfdDispatchDeviceControl+0x3b 96647ae0 8167a0e0 818727af 9512d970 8bc0edd0 nt!IovCallDriver+0x73 96647af4 818727af 00000000 9512d970 9512da4c nt!IofCallDriver+0x1b 96647b14 81875afe 8bc0edd0 85e81198 00000000 nt!IopSynchronousServiceTail+0x1f8 96647bd0 818bcab0 00000054 9512d970 00000000 nt!IopXxxControlFile+0x810 96647c04 81680db6 00000054 00000000 00000000 nt!NtDeviceIoControlFile+0x2a 96647c04 77716c74 00000054 00000000 00000000 nt!KiSystemServicePostCall 0034f8b8 7771542c 75acab4d 00000054 00000000 ntdll!KiFastSystemCallRet 0034f8bc 75acab4d 00000054 00000000 00000000 ntdll!ZwDeviceIoControlFile+0xc 0034f91c 7712bb75 00000054 00012003 001530d0 KERNELBASE!DeviceIoControl+0xf6 0034f948 00141141 00000054 00012003 001530d0 kernel32!DeviceIoControlImplementation+0x80 [...] --- cut --- We suspect it should be possible to extract some of the junk pool memory back to user-mode, e.g. through the IP address and port assigned to the socket in question. The issue reproduces on Windows 7, and is easiest to observe with Special Pools enabled for the afd.sys module. Attached is a afdbind_doublefetch.cpp file which is the C++ source code of a proof-of-concept program for the issue. ----------[ Buffer size sanitization logic in afd!AfdBind and tcpip!TcpBindEndpoint ]---------- As discussed before, the sockaddr_size[] array used during input structure size sanitization is full of 0x00's, except for indexes 0x2 and 0x17 (which are probably the only two valid packet types). Thus, if we call an IOCTL with the WORD containing a value other than the two, the sanitization will be virtually non-existent, and the input buffer is allowed to have any size at all. However, if we take a look at the tcpip!TcpBindEndpoint routine, we can see the following logic: --- cut --- .text:000533EC cmp word ptr [esi], 2 .text:000533F0 lea edi, [ebx+1Ch] .text:000533F3 jnz short loc_533FB .text:000533F5 movsd .text:000533F6 movsd .text:000533F7 movsd .text:000533F8 movsd .text:000533F9 jmp short loc_53400 .text:000533FB .text:000533FB loc_533FB: .text:000533FB push 7 .text:000533FD pop ecx .text:000533FE rep movsd --- cut --- which translates to: --- cut --- if (lpKernelStruct->dwStructType == 2) { memcpy(lpNewStruct, lpKernelStruct, 0x10); } else { memcpy(lpNewStruct, lpKernelStruct, 0x1C); } --- cut --- In other words, if the first WORD doesn't equal 2, the function assumes that it must equal 0x17 and thus the buffer must have been verified to be at least 0x1C bytes long. However, as the dwStructType value and buffer size may be arbitrary, an out-of-bounds read of at most ~0x1C bytes may occur in the memcpy() call. An excerpt from a subsequent crash is shown below (very similar to the previous one): --- 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: 8b523000, memory referenced Arg2: 00000000, value 0 = read operation, 1 = write operation Arg3: 84e793fe, if non-zero, the address which referenced memory. Arg4: 00000000, (reserved) Debugging Details: ------------------ [...] TRAP_FRAME: 88c67818 -- (.trap 0xffffffff88c67818) ErrCode = 00000000 eax=84492318 ebx=94e30020 ecx=00000003 edx=00000000 esi=8b523000 edi=94e3004c eip=84e793fe esp=88c6788c ebp=88c67898 iopl=0 nv up ei ng nz ac po cy cs=0008 ss=0010 ds=0023 es=0023 fs=0030 gs=0000 efl=00010293 tcpip!TcpBindEndpoint+0x51: 84e793fe f3a5 rep movs dword ptr es:[edi],dword ptr [esi] Resetting default scope LAST_CONTROL_TRANSFER: from 82730dff to 826cc9d8 STACK_TEXT: 88c6736c 82730dff 00000003 fbe6b7bb 00000065 nt!RtlpBreakWithStatusInstruction 88c673bc 827318fd 00000003 00000000 00000004 nt!KiBugCheckDebugBreak+0x1c 88c67780 826df99d 00000050 8b523000 00000000 nt!KeBugCheck2+0x68b 88c67800 82691f98 00000000 8b523000 00000000 nt!MmAccessFault+0x104 88c67800 84e793fe 00000000 8b523000 00000000 nt!KiTrap0E+0xdc 88c67898 84e7939e 95464008 8b8ca896 84492318 tcpip!TcpBindEndpoint+0x51 88c678b8 84e7b900 95464008 88c679cc 00000000 tcpip!TcpIoControlEndpoint+0x199 88c678cc 826dabe5 88c6795c fbe6bd33 00000000 tcpip!TcpTlEndpointIoControlEndpointCalloutRoutine+0x8b 88c67934 84e7689e 84e7b875 88c6795c 00000000 nt!KeExpandKernelStackAndCalloutEx+0x132 88c6796c 8b8c75ed 95464000 88c67901 88c679f8 tcpip!TcpTlEndpointIoControlEndpoint+0x67 88c679a0 8b8c76aa 84e76837 95464008 88c679cc afd!AfdTLIoControl+0x33 88c679b8 8b8caafa 8b54aef0 88c679cc 84492318 afd!AfdTLEndpointIoControl+0x1a 88c679f8 8b8ca88a 84492318 8b54aef0 84492318 afd!AfdTLBind+0x4b 88c67a40 8b8baeb8 84492318 8b54aef0 00000000 afd!AfdTLBindSecurity+0x108 88c67aac 8b8c72bc 95463210 84492318 88c67ae0 afd!AfdBind+0x283 88c67abc 8298b4d9 86cac1a0 84492318 95463210 afd!AfdDispatchDeviceControl+0x3b 88c67ae0 826880e0 828807af 84492318 86cac1a0 nt!IovCallDriver+0x73 88c67af4 828807af 00000000 84492318 844923f4 nt!IofCallDriver+0x1b 88c67b14 82883afe 86cac1a0 95463210 00000000 nt!IopSynchronousServiceTail+0x1f8 88c67bd0 828caab0 00000054 84492318 00000000 nt!IopXxxControlFile+0x810 88c67c04 8268edb6 00000054 00000000 00000000 nt!NtDeviceIoControlFile+0x2a 88c67c04 775a6c74 00000054 00000000 00000000 nt!KiSystemServicePostCall 0024faa4 775a542c 7570ab4d 00000054 00000000 ntdll!KiFastSystemCallRet 0024faa8 7570ab4d 00000054 00000000 00000000 ntdll!NtDeviceIoControlFile+0xc 0024fb08 75d1bb75 00000054 00012003 0024fc38 KERNELBASE!DeviceIoControl+0xf6 0024fb34 010b120b 00000054 00012003 0024fc38 kernel32!DeviceIoControlImplementation+0x80 [...] --- cut --- The issue reproduces on Windows 7, and is easiest to observe with Special Pools enabled for the afd.sys module. Attached is a afdbind_tcpip_oob_read.cpp file which is the C++ source code of a proof-of-concept program for the issue. Proofs of Concept: https://gitlab.com/exploit-database/exploitdb-bin-sploits/-/raw/main/bin-sploits/42009.zip

Products Mentioned

Configuraton 0

Microsoft>>Windows_7 >> Version *

Microsoft>>Windows_server_2008 >> Version *

Microsoft>>Windows_server_2008 >> Version r2

Microsoft>>Windows_server_2012 >> Version -

References

http://www.securityfocus.com/bid/98111
Tags : vdb-entry, x_refsource_BID
http://www.securitytracker.com/id/1038445
Tags : vdb-entry, x_refsource_SECTRACK
https://www.exploit-db.com/exploits/42009/
Tags : exploit, x_refsource_EXPLOIT-DB
The information presented on CVE Find originates from several carefully selected reference sources. CVE data is provided by MITRE Corporation and the National Vulnerability Database (NVD). The Known Exploited Vulnerabilities (KEV) catalog is sourced from the Cybersecurity and Infrastructure Security Agency (CISA), while EPSS scores come from FIRST.org. Additionally, data regarding software weaknesses (CWE) and common attack patterns (CAPEC) is maintained by MITRE Corporation, and information on hardware and software configurations (CPE) is provided by the NVD.