When the CODESYS V3 runtime allocates memory for channel buffers, it reads the MaxChannels and BufferSize settings under the [CmpChannelServer] section in the configuration file (i.e., CODESYSControl.cfg, Gateway.cfg). The integer settings in the configuration file are treated as signed int32. If BufferSize is a large positive number (i.e, 0x7fffffff) and MaxChannels * 2 is a negative number (i.e., MaxChannels = 0x7fffffff), it will cause the runtime to allocate a large number of bytes (i.e., 0x7ffff008) from the heap. This could cause SysMemAllocData() to fail, resulting in an error in the log:
01571694396373, 0x0000000a, 4, 17, 0, Failed to allocate memory for channel buffers, no communication channels available
When the channel layer (layer 4) is not available, layer 7 services cannot be run, severely limiting the runtime functionalities.
Additionally, we reported a bug that CODESYS has deemed to be an improvement:
GatewayService.exe implements layer 7 service group 6, which allows manipulation (i.e., get, set, remove operations) of settings in the gateway configuration file. To access the layer 7 services, a valid session ID is required. It looks like an unauthenticated, remote attacker could login as an anonymous user to obtain a session ID. On a PLC (i.e., CODESYSControlService.exe) that also implements service group 6, the CmpUserMgr component is seen to be included in the runtime to prevent anonymous access. However, it does not appear the CmpUserMgr component is implemented in GatewayService.exe. So it's unclear whether GatewayService.exe can be configured to prevent an unauthenticated remote attacker from changing the configuration file.
When combining both issues, an unauthenticated remote attacker can cause a DoS on GatewayService.exe when it restarts.
The attached PoC attempts to write the following settings to Gateway.cfg: