Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Cisco buffer overflow vulnerability with remote code execution

tools.cisco.com

Post reply on HN
Print view View original

11–20 of 23 posts

Re: Cisco buffer overflow vulnerability with remote code execution

#11

Post by kjs3 »

code777777 wrote: post #7
feld wrote: post #5

Earlier quoted context omitted.

People who have firewall needs and no skills hire people who know what Cisco products are, get someone to implement an ASA for them, and then it sits for years without any software updates. Maybe a rule update every now and then, but definitely no software updates.

Perhaps most do but I see a different trend these days. "The network" is a lot more important now since so many things are cloud-based. 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 Many of those clients have a maintenance agreement with us that includes these sorts of things…

I can think of at least 8 of my clients (between 500 and 15000 employees, with probably 100 ASAs total) still on ASA version 8, much less 9. For some, the more critical in infrastructure, the less they want to update.

Re: Cisco buffer overflow vulnerability with remote code execution

#12

Post by qwijibo »

code777777 wrote: post #7
feld wrote: post #5

Earlier quoted context omitted.

People who have firewall needs and no skills hire people who know what Cisco products are, get someone to implement an ASA for them, and then it sits for years without any software updates. Maybe a rule update every now and then, but definitely no software updates.

Perhaps most do but I see a different trend these days. "The network" is a lot more important now since so many things are cloud-based. 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 Many of those clients have a maintenance agreement with us that includes these sorts of things…

kjs3 - you replied to this and are hellbanned here, as am I apparently.

Re: Cisco buffer overflow vulnerability with remote code execution

#13

Post by virtualwhys »

> 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 the weekend...

Re: Cisco buffer overflow vulnerability with remote code execution

#14

Post by alt219 »

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…

It does seem that Cisco will provide updates if customers don't have a valid SmartNET contract. From the vulnerability disclosure:

> 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.

Re: Cisco buffer overflow vulnerability with remote code execution

#15

Post by EvanKelly »

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…

I think they're suggesting that someone snooping the encrypted traffic coming from the ASA couldn't leverage this vulnerability for easier decryption. (i.e. this is an active, not passive vulnerability).

That's probably clear when they say it allows RCE, but who knows.

Re: Cisco buffer overflow vulnerability with remote code execution

#17

Post by virtualwhys »

alt219 wrote: post #14
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…

It does seem that Cisco will provide updates if customers don't have a valid SmartNET contract. From the vulnerability disclosure: > 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 c…

Thanks, I missed that, just followed:

> Products > Security > Firewalls > Adaptive Security Appliances (ASA) > ASA 5500-X Series Firewalls > > 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.

Re: Cisco buffer overflow vulnerability with remote code execution

#19

Post by TabTwo »

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…

exactly, to the moon. the good news here is, that the bug does not get triggert by forwarding/inspecting Ike traffic.

hope this removes the confusion

Re: Cisco buffer overflow vulnerability with remote code execution

#20

Post by chris_overseas »

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 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.

Post reply on HN