Cisco buffer overflow vulnerability with remote code execution(tools.cisco.com) |
Cisco buffer overflow vulnerability with remote code execution(tools.cisco.com) |
There is also a Snort signature to detect attempts to exploit this vulnerability.
Edit: Gelob, below, is right. There's a really unfortunate "read more" link that hides the important bits on Cisco's documentation and caused my confusion.
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 the weekend...
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 might not be stable.
Early on in the process (after 2-3 email iterations) their customer support called me to say we weren't eligible for a fix because we didn't have a support contract. I'd mentioned in my initial request that we had no contract but also pointed out that the advisory said we didn't need one. I had also provided a link to the advisory in my initial request, so that should not have been an issue. I was then told my request was "very confusing".
Once I finally convinced them we were allowed the update and verified the serial number of our hardware, I was thankfully forward on to tech support. They then checked our firmware version and I was supplied with a patch download URL quite quickly. The actual download was hampered in several ways by their poor website (registration required, browser autocomplete and cut and paste caused their JS validation to fail, and I couldn't get it to work with any browser other than IE). Once I finally had the patch, it applied without issue.
In short - the patch process was long, frustrating, complex, and as a small business owner makes me never want to ever, ever deal with Cisco products again.
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.
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).
> Customers Without Service Contracts > Customers who purchase directly from Cisco but do not hold a Cisco service contract and customers who make purchases through third-party vendors but are unsuccessful in obtaining fixed software through their point of sale should obtain upgrades by contacting the Cisco Technical Assistance Center (TAC): http://www.cisco.com/en/US/support/tsd_cisco_worldwide_conta... > Customers should have the product serial number available and be prepared to provide the URL of this advisory as evidence of entitlement to a free upgrade.
> Products > Security > Firewalls > Adaptive Security Appliances (ASA) > ASA 5500-X Series Firewalls > <your Cisco ASA model> > Software on Chassis > Adaptive Security Appliance (ASA) Software
and was prompted that an active service contract is required. Not that I'm opposed, it's the first thing I'll do prior to upgrading (since 8.2 to 8.3 migration looks non-trivial due to NAT changes, and have no clue what has transpired between 8.3. and 9.1).
Of course this is obviously a sign to just upgrade the hardware and get off the EOL train.
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?
That's probably clear when they say it allows RCE, but who knows.
hope this removes the confusion
Our networking group automated a deployment for the fix and contacted everyone that has ever bought an ASA from our company and updated them. We have ~400 ASAs across the country still have < 50 to go. There are still a few stragglers and the older ASAs need a bit more TLC.
Many of those clients have a maintenance agreement with us that includes these sorts of things and changes. All of them were updated and tested within 24 hours.
We did the same thing for the Juniper exploits (albeit we only had a handful).
EDIT: typos