Wind River VxWorks

Reply
L0 Member

Wind River VxWorks

Is Palo Alto working on signatures/rules for the CVE's listed below ( ICS Advisory (ICSA-19-211-01) )?

 

CVE‐2019‐12255

CVE‐2019‐12256

CVE‐2019‐12260

CVE‐2019‐12257

CVE‐2019‐12261

CVE‐2019‐12263

CVE‐2019‐12258

CVE‐2019‐12262

CVE‐2019‐12264

CVE‐2019‐12259

CVE‐2019‐12265

Tags (2)
L0 Member

Re: Wind River VxWorks

I would like to know this as well. Will this be something we could implement via a signature update or would it have to be something deeper in the inspection of the TCP/IP stack for things like SYN/URG/FIN flags?

L0 Member

Re: Wind River VxWorks

I know this thread is couple months old but I'll post a response anyway. 

 

There are 6 critical vulnerabilities from the Urgent/11 family. 

 

CVE-2019-12256

A specially crafted IP packet sent to the target can cause a stack overflow in the handling of IP options in the header to possibly cause remote code execution. If you have a device (like our NGFW) that can clear IP options from the IPv4 header for ingress traffic, you can neutralize this exploit. Palo Alto Networks NGFW does not clear IP options by default so you can create a specific zone protection profile that drops relevant IP options and apply to the segment where your vulnerable VxWorks device is connected. "Network tab - Zone Protection Profile - add - Packet based attack protection tab" 

clipboard_image_4.png

 

CVE-2019-12255, CVE-2019-12260, CVE-2019-12261, CVE-2019-12263

These 4 vulnerabilities all leverage manipulating TCP URG flag/pointer. Palo Alto Networks NGFW clears URG field as the default, out of the box configuration, neutralizing these attacks. This is a global setting however and cannot be applied only to a specific zone. You can run the following command to check your NGFW's current setting: "show running tcp state"

clipboard_image_1.png

 

From the web GUI, under the Device tab - TCP Settings.

clipboard_image_2.png

 

CVE-2019-12257

Exploiting this vulnerability requires the attacker to send a crafted DHCP server response before the actual DHCP server response gets to the victim host. Configuring security rule from your NGFW to only allow DHCP traffic from your authorized DHCP server can thwart such attacks. This wouldn't obviously work if the attacker was on the same network as the victim host. If such implementation is not feasible due to other devices in the network, consider isolating vulnerable devices to their own network segment/zone(s) to be able to apply the desired FW security rule. 

 

@jesseholland
@Eusono
@tmcneil
@matthewroberson
@KevinMedeiros

 

 

Tags (3)
Like what you see?

Show your appreciation!

Click Like if a post is helpful to you or if you just want to show your support.

Click Accept as Solution to acknowledge that the answer to your question has been provided.

The button appears next to the replies on topics you’ve started. The member who gave the solution and all future visitors to this topic will appreciate it!

These simple actions take just seconds of your time, but go a long way in showing appreciation for community members and the Live Community as a whole!

The Live Community thanks you for your participation!