CVE-2019-1372

Information

DWASSVC service is responsible for managing tenant applications workers (w3wp.exe) in Azure App Service. The workers and DWASSVC communicate with each other using a named pipe. The data sent to this named pipe can be described as the following:

DWORD opcode (4 Bytes) The operation code
DWORD dataLength (4 Bytes) The length of the data
data The actual data

When DWASInterop.dll (Loaded and used by DWASSVC) handles this kind of messages there is an edge case that causes a heap based buffer-overflow.
An attacker can create a rouge app, enumerate the opened handles in its context and find the opened named pipe handle that the worker is using to communicate with DWASSVC. Then the attacker can send it’s own messages directly to the named pipe.

The vulnerability occurs in this code:

IPM_WORKER_ITEM *newWorkerItem; // rax MAPDST
__int64 result; // rax

newWorkerItem = (IPM_WORKER_ITEM *)operator new(len);
if ( !newWorkerItem )
  return 0x8007000Ei64;
memcpy(newWorkerItem, this->workerItem, this->workerItemSize);
j_j_free(this->workerItem);
this->workerItemSize = len;
result = 0i64;
this->workerItem = newWorkerItem;
return result;

The this->workerItem is a structure that describes the received message.
Usually, the len passed to the new operator is calculated automatically if the message was sent through the exposed API. However if an attacker sends a message directly to the pipe, the len can be changed to any value because it is part of the message structure (dataLength).

This means an attacker can send a similar message:

DWORD opcode (4 Bytes) 16 (Doesn’t really matter)
DWORD dataLength (4 Bytes) 0
data A * 100 (Large Data)

In the above code, a buffer will be allocated with the size of 0, and the memcpy will be performed with the size of 108 resulting in a heap-based buffer overflow. Exploiting this vulnerability could allow an attacker to execute code in the context of NT AUTHORITY\system thereby escaping the Sandbox.