LRQA have discovered three vulnerabilities in Carbon Black; CVE-2016-9570, CVE-2016-9568 and CVE-2016-9569. Two of these have been patched at the time of writing.
CVE-2016-9570
- Module: cb.exe (SRC-149)
- Version: 5.1.1.60603
- Bug Type: Read-Out-Of-Bounds
- Impact: DoS
- Prerequisites: Hijack NetMon Pipe
- Severity: Medium
- Status: Remediated
Note: The following technical details are taken from the x86 build of the Carbon Black Sensor module. Variable sizes might change in x64 build.
Overview
The Carbon Black sensor receives data through the “\\.\pipe\netmon” named pipe and selects the appropriate handler based on a number that goes from 0 to 9.
If we send number ‘4’ as a command type then the DWORD store at offset (Buffer_Base + 0x7B) it will be interpreted as size for memory allocation. If we indicate 0x41414141 as size, the final size requested will be (size + 0x50). The driver has already checked if supplied size value is zero or a negative number, thus 0x80000000 and greater, so there are no integer overflows in this case.
014FC09B PUSH ECX ;HeapSize = 0x41414150 014FC09C PUSH 0 ;Flags = 0 014FC09E PUSH EAX ;hHeap 014FC09F CALL DWORD PTR DS:[<&KERNEL32.HeapAlloc>]
If the allocation succeeds, the driver will copy (size – 1) bytes to that buffer without validating the size of the buffer that keeps the input data, which will cause the Carbon Black Sensor to crash through an invalid pointer dereference. A memory access violation on read in this case.
Recommendation
Perform additional validation checks over the input that is processed through the named pipe.
CVE-2016-9568
- Module: cbstream.sys (SRC-148)
- Version: 5.1.1.60603
- Bug Type: Design Security Issue
- Impact: Perform unauthorized actions
- Prerequisites: Hijack NetMon Pipe
- Severity: Medium
- Status: Unfixed
Overview
This issue has not yet been fixed by Carbon Black, so LRQA have opted to release only the limited details above for now.
CVE-2016-9569
- Module: cbstream.sys (SRC-147)
- Version: 5.1.1.60603
- IOCTL: 0x62430028
- Bug Type: Read-Out-Of-Bounds
- Impact: DoS
- Prerequisites: Admin Privileges
- Severity: Low
- Status: Remediated
Note: The following technical details are taken from the x86 build of the driver module. Variable sizes might change in x64 build.
Overview
When supplying the aforementioned IOCTL code, the driver will interpret the second DWORD (4 bytes) as a counter and the third DWORD as a value to search for in an allocated buffer.
The issue is that if the supplied counter is too big, then while parsing a memory allocation trying to find a match for the supplied value (3rd DWORD) it will eventually reach an address that doesn’t belong to an allocated memory page (read-out-of-bounds) resulting into an invalid pointer dereference which will lead to system crash, aka BSoD.
Disassembly
Disassembly
WinDBG – Crash Sample
ECX: counter limit provided through user input via IOCTL
eax=88128000 ebx=00000001 ecx=41414141 edx=00000008 esi=0064c33c edi=8078f6fc
eip=a06dc366 esp=8078f4e0 ebp=8078f4e4 iopl=0 nv up ei ng nz na po cy
cs=0008 ss=0010 ds=0023 es=0023 fs=0030 gs=0000 efl=00010283
cbstream+0x3366:
a06dc366 8b10 mov edx,dword ptr [eax] ds:0023:88128000=???????? <- Invalid pointer dereference
Recommendation
Validate that ‘counter’ parameter doesn’t exceed a specific value. If that value is not ‘known’ then perform boundary checks against the buffer by validating the address to read from before that happens.
