Cisco buffer overflow vulnerability with remote code execution • Hacker News Board

Re: Cisco buffer overflow vulnerability with remote code execution

#21

Post by virtualwhys » Sun, Feb 14, 2016, 12:06 AM UTC

chris_overseas wrote: post #20

virtualwhys wrote: post #13

> Note: Only traffic directed to the affected system can be used to exploit this vulnerability. I'm confused, how else would the system be compromised, by directing traffic at the moon? Running an EOL ASA in colo on v8.2. Have been holding out due to the post-v8.2 changes to NAT. Looks like you need a SmartNET contract to get the fix, unfortunate, many legacy devices will left vulnerable as a result. Well, there goes…

You don't need a SmartNET contract, but... We own affected hardware and don't have a support contract. It took me about four hours working my way through Cisco customer and tech support to get updated. Now that the interim patch is applied (complete with bugs mentioned elsewhere in this thread?), it doesn't sound like we'll easily be able to get a bug-free update at a later date. So while we're hopefully safe, we mig…

Just called Cisco TAC and am heading down the same road shortly ;-)

I'm going to renew SmartNET not for this particular vulnerability but for simply getting over the NAT hump from to 8.2 to 8.3 (and whatever other gotchas have come up between 8.2 and latest 9.x). Cisco TAC has been pretty awesome in the past, definitely don't trust myself to navigate the upgrade path in production.

Re: Cisco buffer overflow vulnerability with remote code execution

#22

Post by jlgaddis » Sun, Feb 14, 2016, 10:06 AM UTC

virtualwhys wrote: post #13

> Note: Only traffic directed to the affected system can be used to exploit this vulnerability. I'm confused, how else would the system be compromised, by directing traffic at the moon? Running an EOL ASA in colo on v8.2. Have been holding out due to the post-v8.2 changes to NAT. Looks like you need a SmartNET contract to get the fix, unfortunate, many legacy devices will left vulnerable as a result. Well, there goes…

They mean just what they said: "traffic directed TO the affected system" (emphasis mine).

If you're not used to dealing with routers on a regular basis, that may not make sense.

Then you realize that there's also traffic passing through the system (i.e., being forwarded).

Basically, the key difference is that only UDP packets with a destination IP address belonging to the firewall can trigger the vulnerability. UDP packets with a destination IP address belonging to something else (e.g., a server behind the firewall) that simply pass through the router will not trigger it.

Does that help clarify it a bit?

Re: Cisco buffer overflow vulnerability with remote code execution

#23

Post by jlgaddis » Sun, Feb 14, 2016, 10:10 AM UTC

chris_overseas wrote: post #20

virtualwhys wrote: post #13

> Note: Only traffic directed to the affected system can be used to exploit this vulnerability. I'm confused, how else would the system be compromised, by directing traffic at the moon? Running an EOL ASA in colo on v8.2. Have been holding out due to the post-v8.2 changes to NAT. Looks like you need a SmartNET contract to get the fix, unfortunate, many legacy devices will left vulnerable as a result. Well, there goes…

You don't need a SmartNET contract, but... We own affected hardware and don't have a support contract. It took me about four hours working my way through Cisco customer and tech support to get updated. Now that the interim patch is applied (complete with bugs mentioned elsewhere in this thread?), it doesn't sound like we'll easily be able to get a bug-free update at a later date. So while we're hopefully safe, we mig…

That's why us Cisco guys get paid the big bucks. :)

P.S. There's also a public, super-duper secret FTP server you can log into with your shiny new Cisco credentials. If it's still around, that is, I fortunately haven't had to grab any images in a long time (yay for junior network guys).