Vulnerabilities > CVE-2016-9038 - Race Condition vulnerability in Sophos Invincea-X 6.1.324058
Attack vector
LOCAL Attack complexity
HIGH Privileges required
LOW Confidentiality impact
HIGH Integrity impact
HIGH Availability impact
HIGH Summary
An exploitable double fetch vulnerability exists in the SboxDrv.sys driver functionality of Invincea-X 6.1.3-24058. A specially crafted input buffer and race condition can result in kernel memory corruption, which could result in privilege escalation. An attacker needs to execute a special application locally to trigger this vulnerability.
Vulnerable Configurations
| Part | Description | Count |
|---|---|---|
| Application | 1 |
Common Weakness Enumeration (CWE)
Common Attack Pattern Enumeration and Classification (CAPEC)
- Leveraging Race Conditions This attack targets a race condition occurring when multiple processes access and manipulate the same resource concurrently and the outcome of the execution depends on the particular order in which the access takes place. The attacker can leverage a race condition by "running the race", modifying the resource and modifying the normal execution flow. For instance a race condition can occur while accessing a file, the attacker can trick the system by replacing the original file with his version and cause the system to read the malicious file.
- Leveraging Time-of-Check and Time-of-Use (TOCTOU) Race Conditions This attack targets a race condition occurring between the time of check (state) for a resource and the time of use of a resource. The typical example is the file access. The attacker can leverage a file access race condition by "running the race", meaning that he would modify the resource between the first time the target program accesses the file and the time the target program uses the file. During that period of time, the attacker could do something such as replace the file and cause an escalation of privilege.
Seebug
| bulletinFamily | exploit |
| description | ### Summary An exploitable double fetch vulnerability exists in the SboxDrv.sys driver functionality of Invincea-X 6.1.3-24058. A specially crafted input buffer and race condition can result in kernel memory corruption, which could result in privilege escalation. An attacker needs to execute a special application locally to trigger this vulnerability. ### Tested Versions Invincea-X 6.1.3-24058 (Dell Protected Workspace) ### Product URLs https://www.invincea.com/solution-overview/ ### CVSSv3 Score 8.1 - CVSS:3.0/AV:L/AC:H/PR:L/UI:N/S:C/C:H/I:H/A:H ### Details This vulnerability is present in the SboxDrv.sys driver which is a part of Invincea-X (Dell Protected Workspace).This product provides sandbox functionality for Windows environments. Because of weak permissions set on the driver any malicious application can communicate with driver. The application can also provide pointer value that is double fetched in the kernel, allowing an attacker to cause a race condition resulting in memory corruption which can lead to local privilege escalation. Diving into the details we need to start with permission sets on device created by vulnerable driver. Vectors of attacks are definitely increased due to the weak permissions set on the '\Device\SandboxDriverApi' device created by the SboxDrv.sys driver which gives group Everyone full access to this device. ``` accesschk.exe -o \Device\SandboxDriverApi \Device\SandboxDriverApi Type: Device RW Everyone RW NT AUTHORITY\SYSTEM RW BUILTIN\Administrators R NT AUTHORITY\RESTRICTED ``` The driver handles a few IOCTLs codes but one of them (0x222007) is especially rich and uses the first DWORD in the input buffer to decide what particular function is executed. Let's investigate the vulnerable function which is launched when first DWORD in input buffer is set to 0x12340001: ``` .text:004014B0 ; signed int __stdcall sub_4014B0(int a1, DWORD inputBuffer) .text:004014B0 sub_4014B0 proc near ; DATA XREF: sub_423070+105o .text:004014B0 .text:004014B0 a1 = dword ptr 8 .text:004014B0 inputBuffer = dword ptr 0Ch .text:004014B0 .text:004014B0 push ebp .text:004014B1 mov ebp, esp .text:004014B3 push edi .text:004014B4 mov edi, [ebp+inputBuffer] .text:004014B7 mov edx, [edi+8] .text:004014BA test edx, edx .text:004014BC jnz short loc_4014C8 .text:004014BE mov eax, 0C000000Dh .text:004014C3 pop edi .text:004014C4 pop ebp .text:004014C5 retn 8 .text:004014C8 ; --------------------------------------------------------------------------- .text:004014C8 .text:004014C8 loc_4014C8: ; CODE XREF: sub_4014B0+Cj .text:004014C8 mov eax, ver_string .text:004014CD push esi .text:004014CE lea esi, [eax+2] .text:004014D1 .text:004014D1 loc_4014D1: ; CODE XREF: sub_4014B0+2Aj .text:004014D1 mov cx, [eax] .text:004014D4 add eax, 2 .text:004014D7 test cx, cx .text:004014DA jnz short loc_4014D1 .text:004014DC sub eax, esi .text:004014DE sar eax, 1 .text:004014E0 push 2 ; Alignment .text:004014E2 lea esi, [eax+eax+2] .text:004014E6 push esi ; Length .text:004014E7 push edx ; Address .text:004014E8 call ds:ProbeForWrite .text:004014EE mov eax, ver_string .text:004014F3 mov ecx, [edi+8] .text:004014F6 push esi ; size_t .text:004014F7 push eax ; void * .text:004014F8 push ecx ; void * .text:004014F9 call memcpy .text:004014FE add esp, 0Ch .text:00401501 pop esi .text:00401502 xor eax, eax .text:00401504 pop edi .text:00401505 pop ebp .text:00401506 retn 8 .text:00401506 sub_4014B0 endp ``` At address `004014B4` we see that inputBuffer pointer gets put into the `edi` register and its later also used from this register. Next at `004014B7` a pointer specified by user at offset +8 in inputBuffer is moved to `edx`. The intended purpose of this pointer is to hold the version of the sandbox driver. We see at address `004014E8` a very important check is done on the `edx` value using ProbeForWrite before a copy operation is made to this buffer. However, a double fetch vulnerability appears at` 004014F3` where the buffer pointer value to which driver version should be copied is again read from `inputBuffer (edi + 8)` instead of using the checked pointer value kept in `edx`. This vulnerability opens the possibility for race condition where a malicious application changes the pointer value between ProbeForWrite and its usage in memcpy. Finally that situation will lead to an arbitrary write in kernel address space. Pseudo-code presenting vulnerable code: ``` signed int __stdcall sub_4014B0(int a1, struct_inputBuffer *inputBuffer) void *inVerBufferLocalPtr; // edx@1 unsigned int v4; // esi@3 inVerBufferLocalPtr = inputBuffer->inVerBuffer; if ( !inVerBufferLocalPtr ) return 0xC000000D; v4 = 2 * wcslen((const unsigned __int16 *)ver_string) + 2; ProbeForWrite(inVerBufferLocalPtr, v4, 2u); memcpy(inputBuffer->inVerBuffer, ver_string, v4); return 0; ``` ### Timeline * 2016-12-12 - Vendor Disclosure * 2017-06-30 - Public Release ### CREDIT * Discovered by Marcin 'Icewall' Noga of Cisco Talos. |
| id | SSV:96478 |
| last seen | 2017-11-19 |
| modified | 2017-09-14 |
| published | 2017-09-14 |
| reporter | Root |
| title | Invincea-X SboxDrv.sys Version Number Query Local Privilege Escalation Vulnerability(CVE-2016-9038) |
Talos
| id | TALOS-2016-0256 |
| last seen | 2019-05-29 |
| published | 2017-06-30 |
| reporter | Talos Intelligence |
| source | http://www.talosintelligence.com/vulnerability_reports/TALOS-2016-0256 |
| title | Invincea-X SboxDrv.sys Version Number Query Local Privilege Escalation Vulnerability |