Carbon Black – Security Advisories: CVE-2016-9570, CVE-2016-9568 and CVE-2016-9569

Nettitude 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.


  • Module: cb.exe (SRC-149)
  • Version:
  • 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.


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.

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.


Perform additional validation checks over the input that is processed through the named pipe.


  • Module: cbstream.sys (SRC-148)
  • Version:
  • Bug Type: Design Security Issue
  • Impact: Perform unauthorized actions
  • Prerequisites: Hijack NetMon Pipe
  • Severity: Medium
  • Status: Unfixed


This issue has not yet been fixed by Carbon Black, so Nettitude have opted to release only the limited details above for now.


  • Module: cbstream.sys (SRC-147)
  • Version:
  • 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.


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.




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


a06dc366 8b10   mov     edx,dword ptr [eax]  ds:0023:88128000=???????? <- Invalid pointer dereference


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.