Cisco PIX SSH/telnet dDOS vulnerability CSCdy51810

From: Nils Reichen (nreichen@lanexpert.ch)
Date: 11/05/02


Date: 5 Nov 2002 21:20:04 -0000
From: Nils Reichen <nreichen@lanexpert.ch>
To: bugtraq@securityfocus.com


('binary' encoding is not supported, stored as-is)

Security Advisory 05.11.02:

Title : Cisco PIX SSH/telnet DOS vulnerability CSCdy51810
Reporter : Nils Reichen LANexpert SA
Affected software : PIX OS 6.2.2 (and probably old version)
Risk : High
Date : November 5, 2002
URL: Full description should be posted in few days on
http://www.giac.org/GCIA.php

[1] Summary

A vulnerability in the TCP/IP stack allow a remote
attacker run a
denial of service attack against the PIX firewall.

This vulnerability is due to a wrong handling of the
subnet address
by the PIX OS stack. If the SSH or telnet daemon is
used, the PIX
will answer to connection request sent to the subnet
address.
The use of the subnet address as destination bypass the
allowed
other filter.

DDOS attack exploiting this vulnerability may produce
memory fragmentation.

[2] Affected software

Version 6.2.2 has been confirmed as vulnerable.
Older versions have not been confirmed, but due to the
stack level of this vulnerability, they could be
supposed vulnerable.

[3] Patch

Interim build 6.2.2.111 is available for Cisco
customer/partner
through the Cisco Technical Assistance Center
http://www.cisco.com/tac

[4] Testing environments

PIX 515
OS version 6.2.2
Only few inside hosts allowed to access the PIX using
SSH / telnet
Naptha tool v1.1 from BindView's RAZOR Security Team

[5] Required Knowledge

TCP
PIX firewall

[6] Technical Details

The PIX firewall respond to TCP SYN packet sent to the
subnet address (first IP of the subnet) for SSH and
telnet service. This behavior is seen if at least one
inside host is allowed to access the PIX using SSH
and/or telnet. In this case,
the TCP three-way handshaking will be completed for any
external host targeting
the subnet address.

Test conduced with the Naptha tool v1.1 (from
BindView's RAZOR team) show the free memory counter
displayed with the "show memory" decreasing. This test
was performed by opening
TCP connections using subnet address as destination and
never close it.
The "show memory" command shows the largest contiguous
free memory.

During the test using one attacker host, the free
memory shown decreased at 8kbytes/sec.

A DDOS attack may lead to fragment all the free memory.

TCPdump trace:
07:32:38.409393 151.100.89.67.4268 > MY.NET.97.128.22:
S 1381191936:1381191936(0) win 32120 <mss
1460,sackOK,timestamp 542804848[|tcp]> (DF) (ttl 48, id
33829, len 60)
07:32:38.409556 MY.NET.97.128.22 > 151.100.89.67.4268:
S [tcp sum ok] 872965664:872965664(0) ack 1381191937
win 4096 <mss 1460> (ttl 255, id 6173, len 44)
07:32:38.452593 151.100.89.67.4268 > MY.NET.97.128.22:
. [tcp sum ok] 1:1(0) ack 1 win 32120 (DF) (ttl 48, id
33831, len 40)
07:32:38.453312 MY.NET.97.254.22 > 151.100.89.67.4268:
P 872965665:872965684(19) ack 1381191937 win 4096 (ttl
255, id 6174, len 59)
07:32:38.497426 151.100.89.67.4268 > MY.NET.97.254.22:
R [tcp sum ok] 1381191937:1381191937(0) win 0 (ttl 239,
id 33833, len 40)
07:32:48.482733 151.100.89.67.4268 > MY.NET.97.128.22:
F [tcp sum ok] 1:1(0) ack 1 win 32120 (DF) (ttl 48, id
34171, len 40)

[7] Exploit Code

Not included in this advisory on purpose

[8] Workaround

Filter inbound SSH and telnet traffic targeted to the
PIX external subnet address
and interface address on the upstream router.

[9] Timeline

Aug 28, 2002 Issue discovered
Aug 30, 2002 Vendor notified, Cisco Systems PSIRT team
notified by the TAC
Sep 03, 2002 Vendor confirmed the issue, bug referenced:
CSCdy51810
Sep 04, 2002 IDS Europe mailing list notified
Sep 13, 2002 New build with fix available
Nov 05, 2002 Public disclosure on Bugtraq mailing list

[10] Correlation / Vendor status
No Common Vulnerabilities and Exposures (CVE)
identification assigned now

Vendor referenced ID for this issue: CSCdy51810
New OS build with patch released: 6.2.2.111

Vendor don't have plans to issue security advisory,
vendor PSIRT
(Product Security Incident Response Team) is
considering the problem as "unexpected behavior".

[11] Credit

Discovery and exploitation Research:
Nils Reichen GCIA CCIE#6763
nreichen@lanexpert.ch

[12] Disclaimer

The information within this paper may change without
notice.
Use of this information constitutes acceptance for use
in an AS IS
condition. There are NO warranties with regard to this
information.
In no event shall the author or an entity where he
belongs be liable
for any damages whatsoever arising out of or
in connection with the use or spread of this information.
Any use of this information is at the user's own risk.

[13] Feedback

Please send suggestions, updates, and comments to:
Nils Reichen LANexpert SA
http://www.lanexpert.ch/
Official : nreichen@lanexpert.ch



Relevant Pages

  • Re: Someone can explain this to me?
    ... > Cisco3640 core router as dgw of the network, ... > Eigrp protocol running on all the devices except the pix. ... > 3640 (remember, this is the dgw of the subnet), all seems ok. ... It sounds like the 1712 is advertising a route to 172.16.1.107 to the ...
    (comp.dcom.sys.cisco)
  • Someone can explain this to me?
    ... Class B subnet 172.16.0.0/16 with about 500 hosts. ... Cisco Pix506 vpn gateway, address 172.16.1.107 ... Eigrp protocol running on all the devices except the pix. ...
    (comp.dcom.sys.cisco)
  • Changed Inside IP subnet on PIX 501, cant VPN to PIX 515
    ... So I have a PIX 501 that I configured to use the 10.14.0.0/16 subnet. ... Outside Interface is DHCP, ComCast Internet ... Outside interface it DHCP/PPPoE, AT&T DSL Internet ...
    (comp.dcom.sys.cisco)
  • Re: Client Machine cannot see Active Directory
    ... > 3.0 uses a netgear wireless router to allow wireless access for some ... > 0.0 is the subnet for our remote location. ... > by a hardware vpn between a Cisco Pix 515 and a Cisco Pix 501. ... is the client having problems accessing AD on the wireless 3.x subnet? ...
    (microsoft.public.win2000.active_directory)
  • Re: Cisco PIX SSH/telnet dDOS vulnerability CSCdy51810
    ... The TCP stack on the PIX is non RFC compliant in responding to TCP packets ... A router does not allow directed broadcasts by default so such behavior can ... PIX releases unused memory and will allocate memory using a best fit scheme ...
    (Bugtraq)

Quantcast