ASA ssh timeout vulnerability

[Christian Jorge]

Hello

Is there anyone that face this recent vulnerability?

http://tools.cisco.com/security/center/viewAlert.x?alertId=27927

http://tools.cisco.com/Support/BugToolKit/search/getBugDetails.do?method=fetchBugDetails&bugId=CSCtc59462

My understanding is that for ASA 8.4.1 and prior, there's a vulnerability that opening many ssh sessions and one of them times out, the firewalls crashes!

As we have many customers with ASA using 8.2.5(26) (for example) I'd like a confirmation that for fixing that bug I need to upgrade my ASA image to at least 8.4.x.

Case that, I believe that all the former firewall configuration must be reviewed because 8.2.x version has many different commands that 8.4.x (for example, NAT)

Hope that Cisco provide a patch for 8.2.x versions

[Maykol Rojas]

Hello Christian,

For the time being, I dont see a fixed version in the 8.2 trend. Mostlikely the code update may need to go up to 8.4 to be sure that you are not going to run with this issue.

Mike

[Christian Jorge]

I'd like an official confirmation from Cisco, regarding upgrades of prior versions (like 8.2)

It seems that this vulnerability could affect many devices in the world and the migration to the last version base (for example 8.4, 9.1) could be traumatic.

Another point, there are some ASA devices (for example old 5520) that could not support newer image versions (due to hardware restrictions, for example 512MB)

How could we deal with this case, only upgrading the hardware?

[Christian Jorge]

Opened a TAC with Cisco for further analyzing

Cisco stated not planning a new patch for software 8.2, informing the possibility to harm all the software structure when trying building a fix. Although software 8.2 is not considered EOL, Cisco recommends an upgrade to newer version of software 8.4 (probably 9.x too)

This way, I think it lasts 2 choices regarding vulnerability/impact:

- continuing to use software 8.2 software knowing about the vulnerability and possibility of crash of the firewall. In a case of failover cluster, there would be a minimal impact due to firewall failover/switchover.

- trying to migrate to newer software versions (and a possibility of impact related to upgrading process and differences in config/commands among software versions)

The question now is: using version 8.2.5(26) which path do I have to choose for minimal impact/downtime:

8.2.5(26)->8.3->8.4->newer 8.4.x ?

[jocamare]

You can go straight from 8.2(5.26) to any of the 8.4 versions.

[Julio Carvajal]

Hello Chrsitian,

As my co-worker correctly mentioned you can go straight to any of the 8.4 versions....

Now take into considerations there are several changes between one version and the other ( NAT,ACL,etc,etc) This to make our lifes easier,

At the beginning might be hard but at the end you will see that everything was done to make everything easier...

Now my recommendation  is GO TO THE newest version .. I mean you have an ASA firewall, take advantage of this beauty and use as many features as you can You will be amazed by the amount of new features add it on the new code.

Just to end here you have  a link so you can check the syntax changes for NAT and ACL's and the recommendations before an upgrade:

https://supportforums.cisco.com/docs/DOC-12690

So have fun man,

Julio Carvajal

[david.tran]

jcarvaja wrote:
Now my recommendation  is GO TO THE newest version .. I mean you have an ASA firewall, take advantage of this beauty and use as many features as you can  You will be amazed by the amount of new features add it on the new code.

This is a typical advice "go to the newest version" from someone who work for cisco and IMHO, a dumb one.  Have you ever worked in operational position?  If you're going to mention the "upside" of the new code, you also need to mention the "downside" of the new code as well, like a lot of bugs in the new code.

Here is the issue:

When you're working with the old code, you know what the issue(s) are and try to come up with a work-around, if possible, because you know exactly what the issue(s) are.  In other words, at least you know what you're dealing with.

When you upgrade to the newest version, you might fix that particular issue but you're going to deal with many unknown issues.  Are you willing to trade a "known" issue with many "unknown" issue(s)?  Reasonable people would not.

I learned this hard lesson many years ago when I was a junior engineer.  I had an  issue with the Pix code 7.0.2 code and the TAC engineer gave me the code 7.2.2(22) to put it on the production environment.  Guess what, the device rebooted itself when I typed "show run" and then "quit".  Yes, it did fix the problem that I had but rebooted the box.

You do NOT use the newest version because of bugs and issues that come with it because the newest version has not been vested yet.  The normal approach is to use a couple releases behind the newest version.

my 2c

[Julio Carvajal]

This is a typical advice "go to the newest version" from someone who work for cisco and IMHO, a dumb one.  Have you ever worked in operational position?  If you're going to mention the "upside" of the new code, you also need to mention the "downside" of the new code as well, like a lot of bugs in the new code.

So wrong......... If I have a device that supports A,B,C,D why would I conform just with A,B.. I mean for me  ( and anyone that knows what this ASA beauty is) I would take as much as I can from the unit. If I stay on that old version I would not do that.

And FYI on every version we have NEW bugs ( I mean nothing is perfect) BUT the previous bugs, those mention on the 8.2 track, 8.3,etc,etc,etc are supposed to be fixed on the new code implementation.

So it's a winning everywhere you see it.. If you want to be limited then be it and stay on that code but if you want to take advantage of what you have... Go to the release notes of the new version, check the NEW features, check the Open bugs and determine if it fits for you.

I learned this hard lesson many years ago when I was a junior engineer.  I had an  issue with the Pix code 7.0.2 code and the TAC engineer gave me the code 7.2.2(22) to put it on the production environment.  Guess what, the device rebooted itself when I typed "show run" and then "quit".  Yes, it did fix the problem that I had but rebooted the box.

As a recommendation, try to check the release notes before an upgrade, that is a must.. Unless that was a new bug it should have appear there.

NOTE: By newest mention we refered to the track version.............

I like this discussions

Have a great one David

[david.tran]

jcarvaja wrote:
If I have a device that supports A,B,C,D why would I conform just with A,B.. I mean for me  ( and anyone that knows what this ASA beauty is) I would take as much as I can from the unit. If I stay on that old version I would not do that. 

       Yes, the device that supports A,B,C,D but I only need to use A & B so why would I need to upgrade to the latest.

       That is asking for trouble with the new bugs.  If you work in a "real" world, you would know that people separate

       the function of Firewall and VPN into two different devices because it is much easier to manage.

jcarvaja wrote:
( and anyone that knows what this ASA beauty is) 

      I would not call the ASA a beauty.  It is still way behind Cisco IOS in term of VPN capability.  Example, it can not

      terminate GRE on the ASA itself, and no BGP either.

jcarvaja wrote:
And FYI on every version we have NEW bugs ( I mean nothing is perfect) BUT the previous bugs, those mention on the 8.2 track, 8.3,etc,etc,etc are supposed to be fixed on the new code implementation.

       That is precisely my point.  They mentioned all the previous bugs have been fixed but you will definitely run into new

       one that you don't know.  You're trading old "known" issues with new "unknown" issues.

jcarvaja wrote:
So it's a winning everywhere you see it.. If you want to be limited then be it and stay on that code but if you want to take advantage of what you have... Go to the release notes of the new version, check the NEW features, check the Open bugs and determine if it fits for you.

      That might help a little bit but one needs to throughly test the code that you will deploy in your environmnet or you

      will be sorry. Your statement of "winning everywhere" shows that you lack the knowledge of working in a production

      environment where downtime is "not" an option.  I can not tell you how many times I've run into issues with sqlnet

      and smtp with ASA that the only option is to disable sqlnet and smtp inspect.  So much for new features.

jcarvaja wrote:
As a recommendation, try to check the release notes before an upgrade, that is a must.. Unless that was a new bug it should have appear there.
NOTE: By newest mention we refered to the track version.............

      That's precisely the point.  You're trading old "known" bugs for new "unknown" bugs. 

      The point I am taking from this is that unless it is a security vulnerability that I have to upgrade, I will stay away

      and try to make it work as much as I can.  With the new code, it needs to vested throughly in-house (not by Cisco)

      because Cisco does not understand my environment.  They may know the ASA but I don't know the applications

      that operate in my environment.

[Julio Carvajal]

Hello David,

We are definetly on a different page

But... well.. Nice talking to you man.

Have a great night .

[Christian Jorge]

I performed my first asa software upgrade. Customer firewall this time has many VPNs configured but few NATs (some exempt and one PAT).

I follow the path: 8.2.5(26) -> 8.3.(2) -> 8.4.5(6)

The result:

- from 8.2.5(26) -> 8.3(2) : NAT-exempt conversion results a lot of garbage (all combinations related to source to all possible destination segments - as Nat-exempt declares no destination segments) and the dangerous "unidirectional" command after each NAT-exempt line converted.

- from 8.3(2) -> 8.4.5(6) there was no change in configuration (not even removing "unidirectional" commands in NAT)

Results: I had to clean all NAT garbage and delete all "unidirectional" command.

Now I have to upgrade a firewall with a huge configuration, mixing PATs, Statics, NAT Exemption, Dynamic NAT.

What exactly path from 8.2.5(26) to 8.4.5(6) should I follow to have a smooth upgrade and convertion?

Shoud I use 8.3(1) path instead of 8.3(2), use both, use 8.4(2) after some 8.3.x to final version?

[Julio Carvajal]

Hello,

Go directly from 8.2 to 8.4.2

Regards

[Christian Jorge]

Hello JCarvaja

My main concern is regarding going from 8.2 directly to 8.4.2, the firewall ignores the NAT configuration. Not even the firewall try to translate or convert to new format.

As told in last topic, we have emulated software 8.4 and input all configuration still in 8.2 format as a script. All VPN configuration, for example has been automatically converted to new format (ikev1/ikev2 commands) after script input.

...but all NAT commands had gone, no convertion done by firewall.

[Julio Carvajal]

Hello

Before the upgrade

remove nat-control

no names

https://supportforums.cisco.com/docs/DOC-12690

The NAT configuration should be done by itself.. Do you see any errors on the flash ( Startup-config errors)

Regards

[Christian Jorge]

No errors found, but in 8.4 emulations, no NATs anyway.

That documment relates only to 8.3 migration, not 8.4. As far as I know, Cisco recommends not jump intermediate versions for zero downtime upgrades (for example 8.2 directly to 8.3).

Even jumping directly from 8.2.5(26) to 8.4(2), my final goal would be 8.4.5(6).

So the your recommendation path would be8.2.5(26)->8.4.2 -> 8.4.5(6)?

Regards and thanks for helping me