Last TCP/IP stack vulnerability

[g.rodegari]

Hi all,

why is Cisco PIX vulnerable to this recent attack?

http://www.cisco.com/en/US/partner/products/products_security_advisory09186a008021ba2f.shtml

I suppose that for any packet that flow throght the PIX, It make an hash to identify if the packet is trusted by the connections state table....

I've to guess much not only IPs Ports and Sequence Numbers...

what do you think about this?

regards,

Graz.

[Solace]

The PIX provides TCP services like PDM my guess is these are suspectable. It would however be cool if Cisco released an update that would allow the PIX to implement the suggested fix, thus protecting all services behind the PIX. (Like a good firewall should?)

http://www.ietf.org/internet-drafts/draft-ietf-tcpm-tcpsecure-00.txt

[cgiulini]

My understanding of this is that since the PIX is maintaining a state table, it is keeping track of the traffic flow, including sequence numbers and window size. If the PIX sees a RST or SYN within the window, it should kill the connection.

Please let me know if I'm missing the point here.

I'm trying to understand how Cisco is addressing this vulnerability with code upgrades. Are they disregarding packets that fall within the window and only accepting the exact sequence number?

When will interim code be released for the PIX? The vulnerability notice states that the code fix is in 6.3.3.132, 6.2.3.109, and 6.1.5.103.

I did post a similar query on another thread. Sorry for repeating but I do find this interesting.

Please let me know if I'm off-target on this.

Regards,

Chad

[g.rodegari]

Hi,

I think you are right.

But I've, probabaly not correct, knowledge that PIX hashs all the packet's headers for one established connection, just for understand if the packet is spoofed or not.

I thought that this control take in exame not only the classic TCP fields but could make a much complex control... probably not. This control is only on the sequence number, IP and ports...

If I'm right, for this trouble, I think It works in a similar fashion that IOS firewall.

thanks,

Graz.

[ehirsel]

Keep these thoughts in mind:

1. The packet sending the reset is not a fragmented one.

2. tcp is coded to handle packets that arrive out of sequence, the pix cannot detect if the packet arrives out of order, unless the seq number is outside of the advertised window range.

The vulnerabilities exist on the pix only if the pix itself is the target, that is the packet does not flow thru it but to it.

It is reasonable to expect tcp frames that are not fragmented arriving out of sequence, but still within the advertised window.

Having a pix does not protect all hosts by default. If I allow ftp to flow to a dmz or inside server, the pix will not protect me from all ftp style attacks.

This tcp one exploits the fact that non-fragmented packets can arrive out of seq and it is up to the host to reassemble them. If the firewall does that, then it is in effect a proxy server and performance can degrade.

[cgiulini]

I understand what you're saying here. What I'm still not clear on is what is being implemented with the "Fixed" Code that Cisco mentions they will release to mitigate this vulnerability.

Thanks,

Chad

[g.rodegari]

Hi,

what do you think about this:

http://www.cisco.com/en/US/partner/products/products_security_advisory09186a008021bc62.shtml

Cisco IOS Firewall (IOS FW) - The Cisco IOS FW monitors packets passing throughout the router and maintains the session state internally. This way, it is possible to "open" required ports and allow traffic to pass and then close them after the session has finished. Since Cisco IOS FW intercepts and examines all packets passing through the device, all TCP sessions passing through the Cisco IOS FW are vulnerable to this attack. This is valid even if the originating and receiving devices themselves are not vulnerable.

G.

[scoe]

The way I read it, PIXes are vulnerable to TCP sessions through it and so more of a concern than other devices.

Presumably the fix will be included in 6.3(4) or whatever the next maintenance release is. My question is can we get the interim 6.3(3.132) if we open a TAC case?

Anyone know?

[jmia]

Stuart,

You can obtain a fix from TAC, Please see following PSIRT advisory:

http://www.cisco.com/warp/public/707/cisco-sa-20040420-tcp-nonios.shtml#fixes

Also, have you got anti-spoofing applied on your pix interfaces?

Jay

[hugodrax]

Actually the pix does reassemble fragmented packets, you can even set a limit or set a policy to deny all fragmented packets thus allowing the fixups to properly inspect those types of packets.