CVE-2019-12256 - VxWorks IPv4 Options Buffer Overflow

This vulnerability can be triggered by a specially crafted IP packet sent to the target device, even as a broadcast or multicast packet. It does not require any specific application or configuration to be running on the device, and it affects any device running VxWorks v6.9.4 or above with a network connection. The vulnerability causes a stack overflow in the handling of IP options in the IPv4 header, making it easy to reach RCE by it.

Recent assessments:

busterb at September 20, 2019 4:46pm UTC reported:

Capability problems with exploitation: an attacker needs a payload to do something other than a DoS. Shellcode for embedded OSes like this needs to be customized for each firmware version and device, which causes problems. This significantly increases the cost for an attacker to do something other than a DoS since it has to be customized to the target. High utility for an advanced actor who has the capability to develop custom payloads and a particular target in mind. Low utility for a low-skilled actor who wants to ‘spray and pray’.

Mitigations: folks should limit opportunities by having strong malformed-packet filtering at the network level. Routers and switches should not be based on VxWorks at the edge.

<https://www.blackhat.com/presentations/bh-usa-09/LINDNER/BHUSA09-Lindner-RouterExploit-SLIDES.pdf&gt;

Another interesting issue with this vulnerability lies around getting the malformed packets from the edge of a network into the core of the target device. Each device needs independent analysis to determine the risk. An edge device would be riskier than a core, one. In this particular case, it’s really surprising however that VxWorks did not just isic, which has been around for years and years to find a vulnerability like this: <http://isic.sourceforge.net/&gt;

Note: when validating the Urgent/11 scanner here: <https://github.com/ArmisSecurity/urgent11-detector&gt; we found that it was unlikely to be effective across even a minimal security boundary of a standard router between network segments. We had a hard time testing it since the malformed packets were discarded by several commodity and not specially-configured kit.

space-r7 at September 17, 2019 8:11pm UTC reported:

Capability problems with exploitation: an attacker needs a payload to do something other than a DoS. Shellcode for embedded OSes like this needs to be customized for each firmware version and device, which causes problems. This significantly increases the cost for an attacker to do something other than a DoS since it has to be customized to the target. High utility for an advanced actor who has the capability to develop custom payloads and a particular target in mind. Low utility for a low-skilled actor who wants to ‘spray and pray’.

Mitigations: folks should limit opportunities by having strong malformed-packet filtering at the network level. Routers and switches should not be based on VxWorks at the edge.

<https://www.blackhat.com/presentations/bh-usa-09/LINDNER/BHUSA09-Lindner-RouterExploit-SLIDES.pdf&gt;

Another interesting issue with this vulnerability lies around getting the malformed packets from the edge of a network into the core of the target device. Each device needs independent analysis to determine the risk. An edge device would be riskier than a core, one. In this particular case, it’s really surprising however that VxWorks did not just isic, which has been around for years and years to find a vulnerability like this: <http://isic.sourceforge.net/&gt;

Note: when validating the Urgent/11 scanner here: <https://github.com/ArmisSecurity/urgent11-detector&gt; we found that it was unlikely to be effective across even a minimal security boundary of a standard router between network segments. We had a hard time testing it since the malformed packets were discarded by several commodity and not specially-configured kit.

Assessed Attacker Value: 3
Assessed Attacker Value: 3Assessed Attacker Value: 3