CODESYS V3 Unauthenticated Webserver Memory Leak DoS

A memory leak condition exists in CODESYSControlService.exe (file version 3.5.15.40) due to failure to free heap-based memory buffers when handling a layer 7, SRV_VISU_REGISTERCLIENT request sent to web server URL endpoint /WebVisuV3. An unauthenticated, remote attacker can exploit this issue, via a series of specially crafted HTTP requests, to increase memory usage in the process which can potentially result in denial of service of the CODESYS V3 runtime system.

In the SRV_VISU_REGISTERCLIENT request, the attacker can specify more than one binary tags. The CmpVisuServer component in the runtime allocates a buffer from the heap to store certain data in a binary tag and stores the buffer pointer in a field of some structure:

__wibu00:0053FB9E      mov     ecx, [ebp+arg_pOut]
__wibu00:0053FBA1      imul    edx, [ecx+ST14.nItems], 2Ch
__wibu00:0053FBA5      push    edx
__wibu00:0053FBA6      push    offset aCmpvisuserver ; "CmpVisuServer"
__wibu00:0053FBAB      call    SysMemAllocData
__wibu00:0053FBB0      add     esp, 0Ch
__wibu00:0053FBB3      mov     ecx, [ebp+arg_pOut]
__wibu00:0053FBB6      mov     [ecx+ST14.pItems], eax

When a subsequent binary tag is processed, another memory buffer is allocated but its pointer is stored in the same location, overwriting the pointer for the previously allocated buffer. When the processing of the SRV_VISU_REGISTERCLIENT request is done, only the last buffer is freed:

__wibu00:0053D361 mov eax, [ebp+ST14.pItems]
 __wibu00:0053D367 push eax
 __wibu00:0053D368 push offset aCmpvisuserver ; "CmpVisuServer"
 __wibu00:0053D36D call SysMemFreeData

The issue can be summed up as:

for (i = 0; i < num_binary_tags; i++)
{
st14->pItems = SysMemAllocData(...,nItems * 0x2C,...);
}
...
SysMemFreeData(...,st14->pItems);

The SRV_VISU_REGISTERCLIENT request is carried in an HTTP header and it appears there is a maximum size (i.e., 48K) for HTTP headers. So the attacker may need to send a large of number requests in order to leak memory to a point where CODESYS runtime components may no longer able to allocate memory for their respective functionalities.

It appears that CODESYSControlService.exe employs some sort of memory garbage collection system, where allocated memory that is no longer in use can be freed. However, the attacker is still able to cause memory allocation failure as indicated in the log file:

2020-04-28T22:37:46Z, 0x00000054, 2, 0, 9, !!!! Warning: VisuInfoTuple not found for RegisterClient, ExtId: 376465, Application=APP
 2020-04-28T22:37:46Z, 0x00000057, 4, 0, 0, **** ERROR: Allocation of clienttags failed 576
 2020-04-28T22:37:46Z, 0x00000054, 2, 0, 9, !!!! Warning: VisuInfoTuple not found for RegisterClient, ExtId: 376467, Application=APP
 2020-04-28T22:37:46Z, 0x00000057, 4, 0, 0, **** ERROR: Allocation of clienttags failed 576
 2020-04-28T22:37:46Z, 0x00000054, 2, 0, 9, !!!! Warning: VisuInfoTuple not found for RegisterClient, ExtId: 376469, Application=APP
 2020-04-28T22:37:46Z, 0x00000057, 4, 0, 0, **** ERROR: Allocation of clienttags failed 576
 2020-04-28T22:37:46Z, 0x00000054, 2, 0, 9, !!!! Warning: VisuInfoTuple not found for RegisterClient, ExtId: 376471, Application=APP
 2020-04-28T22:37:46Z, 0x00000057, 4, 0, 0, **** ERROR: Allocation of clienttags failed 576
 2020-04-28T22:37:46Z, 0x00000054, 2, 0, 9, !!!! Warning: VisuInfoTuple not found for RegisterClient, ExtId: 376473, Application=APP
 2020-04-28T22:37:46Z, 0x00000057, 4, 0, 0, **** ERROR: Allocation of clienttags failed 576
 ...

Proof of Concept