CVE-2019-5075
An exploitable stack buffer overflow vulnerability exists in the command line utility get_coupler_details of the WAGO PFC 200. A specially crafted set of packets sent to the iocheckd service “I/O-Check” can cause a stack buffer overflow in the sub-process get_coupler_details, resulting in code execution. An attacker can send unauthenticated packets to trigger this vulnerability.
WAGO PFC200 Firmware version 03.01.07(13) WAGO PFC200 Firmware version 03.00.39(12) WAGO PFC100 Firmware version 03.00.39(12)
https://www.wago.com/us/pfc200 https://www.wago.com/us/pfc100
9.8 CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H
CWE-805: Buffer Access with Incorrect Length Value
The WAGO PFC200 Controller is one of WAGO’s programmable automation controllers that boasts high cybersecurity standards by including VPN, SSL and firewall software. WAGO controllers are used in many industries including automotive, rail, power engineering, manufacturing, and building management. The WAGO PFC200 Controller communicates via both standard and custom protocols.
The iocheckd service “I/O-Check” implements a custom configuration protocol used by WAGO controllers. The get_coupler_details command line utility uses an incorrect buffer length when copying system data into a stack buffer when generating a response to a message sent to the iocheckd service “I/O-Check”. When values are present for the system values MARKING or WAGONR whose length exceeds 60 bytes, the stack buffer will be overflowed resulting in a crash. Additionally, an attacker can send an unauthenticated packet using the iocheckd protocol to overwrite the MARKING or WAGONR value enabling attacker controlled data to overflow this stack buffer. Since the attacker can control the data that is being copied onto the stack, and invoke get_coupler_details remotely via an iocheckd service “I/O-Check” message this vulnerability results in remote code execution.
There are four different messages that can trigger this vulnerability as outlined in the poc code below.
[Annotated Disassembly / Decompilation output]
sub_120E4 stack frame allocation
.text:000120E4 PUSH {R4-R6,LR}
.text:000120E8 VMOV.I32 Q8, #0
.text:000120EC SUB SP, SP, #0x138
This is allocating the buffer for MARKING value 0x40 in size
.text:000121A0 ADD R4, SP, #0xB8
.text:000121A4 BL strcpy
.text:000121A8 LDR R1, =aPrgdate ; "PRGDATE"
.text:000121AC ADD R0, SP, #0x38
.text:000121B0 BL sub_11D98
.text:000121B4 CMP R0, #0
.text:000121B8 BNE loc_1223C
.text:000121BC LDR R1, =aWagonr ; "WAGONR"
This is allocating the buffer for the WAGONR value 0x40 in size
.text:000121C0 ADD R0, SP, #0x78
.text:000121C4 BL sub_11D98 ; This function overflows the buffer
.text:000121C8 CMP R0, #0
.text:000121CC BNE loc_1223C
.text:000121D0 LDR R1, =aMarking ; "MARKING"
.text:000121D4 MOV R0, R4
.text:000121D8 BL sub_11D98 ; This function overflows the buffer
In sub_11D98:
.text:00011DDC MOV R2, #0x104 ; will overflow because 0x104 > 0x40
.text:00011DE0 MOV R1, R6 ; R1 contains the system value
.text:00011DE4 MOV R0, R7 ; R0 is the stack buffer being overflowed
.text:00011DE8 BL g_strlcpy
In sub_120E4 function epilogue the values for PC and R4-R6 are overwritten with the values from the attacker-controlled WAGONR or MARKING value
.text:000122D0 loc_122D0 ; CODE XREF: sub_120E4+B4↑j
.text:000122D0 ADD SP, SP, #0x138
.text:000122D4 POP {R4-R6,PC}
In process /etc/config-tools/get_coupler_details
Program received signal SIGSEGV, Segmentation fault.
0x58585858 in ?? ()
(gdb) i r
r0 0x0 0
r1 0x78 120
r2 0xffffffff 4294967295
r3 0xbefffbec 3204447212
r4 0x41414141 1094795585
r5 0x41414141 1094795585
r6 0x41414141 1094795585
r7 0x1 1
r8 0x2aa04 174596
r9 0xbeffff09 3204448009
r10 0x2adcc 175564
r11 0x2c 44
r12 0x12a09 76297
sp 0xbefffb70 0xbefffb70
lr 0x122cc 74444
pc 0x58585858 0x58585858
cpsr 0x800f0010 -2146500592
fpscr 0x0 0
(gdb) bt
#0 0x58585858 in ?? ()
#1 0x000122cc in ?? ()
Backtrace stopped: previous frame identical to this frame (corrupt stack?)
This vulnerability could be mitigated by disabling the iocheckd service “I/O-Check” via the Web-based management web application.
2019-07-30 - Vendor disclosure
2019-09-06 - 30+ day follow up
2019-10-02 - 60+ day follow up; vendor acknowledged
2019-10-31 - Vendor passed to CERT@VDE for coordination; Talos extended public disclosure deadline
2019-12-16 - Public Release
Discovered by Kelly Leuschner of Cisco Talos