This email is in response to the BugTraq posting at
http://online.securityfocus.com/archive/1/299046

There are two issues in the original email which are addressed below.

1) The TCP stack on the PIX is non RFC compliant in responding to TCP packets
destined to the network broadcast address.

One could craft a telnet/ssh client to connect to the PIX by sending requests
to the network broadcast address of the subnet the PIX is connected to. Even
if one was able to connect to the PIX, by using such a crafted client, one
would still need an account/password to gain access to the PIX.

Security of the PIX is not compromised.

A router does not allow directed broadcasts by default so such behavior can
only be experienced on the local subnet. If directed broadcast is required
for a subnet then using the ACL option of the directed broadcast command on
the router, TCP directed broadcasts can be filtered out for the subnet.

This nonconformant behavior is being fixed in all upcoming PIX releases by
allowing new TCP sessions to be created only if the packet was sent to the
PIX interface address. Packets sent to the broadcast or subnet address would
be dropped.

2) PIX releases unused memory and will allocate memory using a best fit scheme
which will reuse freed chunks of memory. When allocating memory, the PIX will
first attempt to re-use memory that was freed and not part of the contiguous
heap.

Cisco has performed additional testing and confirms that no fragmentation or
memory leaks are seen based on the attack described in this report.