Thread-topic: Cisco PIX TCP Connection Prevention - answer from Cisco
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Tue, 22 Nov 2005 08:17:54 -0800
> From: "Randy Ivener \(rivener\)" <rivener@xxxxxxxxx>
> Subject: [Full-disclosure] Cisco PIX TCP Connection Prevention
> To: <full-disclosure@xxxxxxxxxxxxxxxxx>
> Cc: "Konstantin V. Gavrilenko" <k.gavrilenko@xxxxxxxxxx>, "psirt
> \(mailer list\)" <psirt@xxxxxxxxx>
> Message-ID:
>
> <6E7590A4D7F8244BA8ECE4FEC6782F650121CEB7@xxxxxxxxxxxxxxxxxxxxxxxxxx>
> Content-Type: text/plain; charset="us-ascii"
>
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Cisco Response
> ==============
>
> This is Cisco PSIRT's response to the statements made by Arhont Ltd.-
> Information Security in its message: [Full-disclosure] Cisco PIX TCP
> Connection Prevention, posted on November 22, 2005.
>
> The original email is available at:
>
> er/038971.
> html
>
>
> This issue is being tracked by two Cisco Bug IDs:
>
>
> * CSCsc14915 -- PIX 6.3 Spoofed TCP SYN packets can block
> legitimate TCP connections
>
> This Bug ID tracks the issue for PIX software version 6.3
> and older. This DDTS is under investigation and while not
> resolved there are workarounds available to mitigate the
> issue.
>
> * CSCsc16014 -- PIX 7.0 Spoofed TCP SYN packets can block
> legitimate TCP connections
>
> This Bug ID tracks the issue for PIX/ASA software version
> 7.0. This DDTS is under investigation and while not
> resolved additional mitigations and workarounds exist
> to limit or eliminate the issue.
>
>
> We would like to thank Arhont Ltd.- Information Security for
> reporting this issue to us.
>
> We greatly appreciate the opportunity to work with researchers on
> security vulnerabilities, and welcome the opportunity to review and
> assist in product reports.
>
>
> Additional Information
> ======================
>
> PIX 6.3
> =======
>
> * CSCsc14915 -- PIX 6.3 Spoofed TCP SYN packets can block
> legitimate TCP connections
>
> This issue affects PIX software version 6.3 and older. The Release
> Note Enclosure for this Bug ID states:
>
> Symptom
> +------
> TCP connections through the firewall may be silently blocked.
>
>
> Conditions
> +---------
>
> By sending a TCP SYN packet with an incorrect checksum through a PIX
> firewall, the PIX will block new TCP connections using the same
> source and destination TCP ports and IP addresses. Connections will
> remain blocked for approximately two minutes after which connections
> will be allowed. This behavior may be seen on all firewall interfaces
> but can be expected to have the most impact on TCP connections
> originating from higher security level interfaces to lower security
> level interfaces.
>
> Since the spoofed packets have an incorrect checksum, they are
> silently discarded by the destination and the firewall will not see a
> RST packet from either the destination or the legitimate source and
> will hold the embryonic connection open until the embryonic
> connection timeout which is 2 minutes by default.
>
> The root cause is due to the spoofed packet creating an embryonic
> connection which sets up the TCP sliding window. A valid packet from
> a real host using the same connection as the spoofed packet sends a
> SYN over the same connection. The sequence number of the valid
> packet is out-of-window and rejected by the firewall's TCP sequence
> number check. Any subsequent retransmissions of the valid packet are
> also out-of-window and are rejected by TCP sequence number check.
>
> Other spoofed TCP SYN packets that create embryonic connections can
> also cause this behavior, blocking legitimate TCP connections until
> the embryonic connection times out.
>
>
> Workarounds
> +----------
>
> Issuing the commands "clear xlate" or "clear local-host <ip address
> on the higher security level interface>" will allow the firewall to
> pass connections again.
>
> TCP connections discarded because of this issue can be verified by
> enabling "debug fixup tcp". 'Out of Window' drops will then generate
> messages that begin with "tcpseq: discard old packet". Debug messages
> may impact firewall performance and should be tested before being
> enabled in a production environment.
>
> For discarded TCP connections originating from lower security level
> interfaces to higher security level interfaces, TCP Intercept can be
> configured on "STATIC" commands by setting the "emb_limit" to 1. This
> results in the PIX proxying all connection attempts after the first
> connection. The PIX will create and send the TCP SYN,ACK from the
> destination to the original source. Since the original TCP SYN packet
> was spoofed, the source IP address will not be tracking the TCP
> connection and it will send a TCP RST to the PIX. The PIX will then
> close the connection originating from the TCP SYN packet with the
> incorrect checksum. TCP Intercept may impact firewall performance and
> should be tested before being enabled in a production environment.
>
>
> Further Problem Description
> +--------------------------
>
> PIX software version 6.3 does not verify the TCP checksum of packets
> transiting through the firewall.
>
> Because the PIX does not verify the TCP checksum, the malformed TCP
> packet is allowed through the firewall in a half-opened, embryonic
> state.
>
> The destination host discards the received malformed segments.
> Because the firewall does not see a return segment from the
> destination host it holds the half-open TCP connection open until the
> embryonic timeout which is set to two minutes for PIX 6.3 and earlier
> software.
>
> Because the firewall is holding a connection open, any additional
> packets with the same protocol, IP addresses, and ports will be
> treated as part of the existing half-open connection. In this case, a
> legitimate SYN packet following the malformed SYN will be discarded
> because it is outside of the window of acceptable sequence numbers
> established by the malformed packet.
>
> For information on configuring the emb_limit as part of the "STATIC"
> command in PIX software version 6.3 refer to:
>
> STATIC
>
> sw/v_63/cm
> dref/s.htm#wp1026694
>
>
>
> PIX/ASA 7.0
> ===========
>
> * CSCsc16014 -- PIX 7.0 Spoofed TCP SYN packets can block
> legitimate TCP connections
>
> This issue affects PIX/ASA software version 7.0. Additional
> mitigations and workarounds to limit or eliminate the issue. The
> Release Note Enclosure for this Bug ID states:
>
>
> Symptom
> +------
>
> TCP connections through the firewall may be silently blocked.
>
>
> Conditions
> +---------
>
> By sending a TCP SYN packet with an invalid checksum through a PIX
> firewall, the PIX will block new TCP connections using the same
> source and destination TCP ports and IP addresses. Connections will
> remain blocked until the embryonic connection timeout which is 30
> seconds by default. This behavior may be seen on all firewall
> interfaces but can be expected to have the most impact on TCP
> connections originating from higher security level interfaces to
> lower security level interfaces.
>
> Since the spoofed packets have an invalid checksum, they are silently
> discarded by the destination and the firewall will not see a RST
> packet from either the destination or the legitimate source and will
> hold the embryonic connection open until the embryonic connection
> timeout which is 30 seconds by default.
>
> The root cause is due to the spoofed packet creating an embryonic
> connection which sets up the TCP sliding window. A valid packet from
> a real host using the same connection as the spoofed packet sends a
> SYN over the same connection. The sequence number of the valid
> packet is out-of-window and rejected by the firewall's TCP sequence
> number check. Any subsequent retransmissions of the valid packet are
> also out-of-window and are rejected by TCP sequence number check.
>
> Other spoofed TCP SYN packets that create embryonic connections can
> also cause this behavior, blocking legitimate TCP connections until
> the embryonic connection times out.
>
> This behavior can be verified by issuing the command: "show asp drop"
>
> The counter for "TCP RST/SYN in window" or "TCP SEQ in SYN/SYNACK
> invalid" should increment for every packet dropped in this manner.
>
>
> Workarounds
> +----------
>
> Several workarounds exist for this issue.
>
> 1. Issuing the commands "clear xlate" or "clear local-host <ip
> address on the higher security level interface>" will allow the
> firewall to pass connections again.
>
>
> 2. The default TCP embryonic connection timeout is 30 seconds. This
> default can also be modified which further mitigates the issue. This
> workaround should be effective regardless of the cause of the issue.
>
> This configuration example sets the TCP embryonic connection timeout
> to 10 seconds for the default "global_policy" policy-map:
>
> access-list tcp_inspection extended permit tcp any any
> access-list tcp_inspection extended deny ip any any
>
> class-map my_inspection_tcp
> match access-list tcp_inspection
>
> policy-map global_policy
> class my_inspection_tcp
> set connection timeout embryonic 0:00:10
>
> service-policy global_policy global
>
>
> 3. TCP Intercept can be configured to allow the PIX to proxy all TCP
> connection attempts originated from behind any firewall interface
> after the first connection. PIX will create and send the TCP SYN,ACK
> from the destination to the original source. Since the original TCP
> SYN packet was spoofed, the source IP address will not be tracking
> the TCP connection and it will send a TCP RST to the PIX. The PIX
> will then close the connection originating from the TCP SYN packet
> with the invalid checksum. This workaround should be effective
> regardless of the cause of the issue.
>
> This example proxies all TCP connection attempts originated from any
> firewall interface
> after the first connection for the default "global_policy"
> policy-map:
>
> access-list tcp_inspection extended permit tcp any any
> access-list tcp_inspection extended deny ip any any
>
> class-map my_inspection_tcp
> match access-list tcp_inspection
>
> policy-map global_policy
> class my_inspection_tcp
> set connection embryonic-conn-max 1
>
> service-policy global_policy global
>
>
> 4. When invalid checksums are the cause of this issue, PIX/ASA
> software version 7.0 can be configured to verify TCP checksums which
> will eliminate the impact. Verifying TCP checksums may impact
> firewall performance and should be tested before being enabled in a
> production environment.
>
> This example verifies TCP packet checksums for the default
> "global_policy" policy-map:
>
> tcp-map verify-chksum
> checksum-verification
>
> access-list tcp_inspection extended permit tcp any any
> access-list tcp_inspection extended deny ip any any
>
> class-map my_inspection_tcp
> match access-list tcp_inspection
>
> policy-map global_policy
> class my_inspection_tcp
> set connection advanced-options verify-chksum
>
> service-policy global_policy global
>
>
>
>
> Cisco Security Procedures
> =========================
>
> Complete information on reporting security vulnerabilities in Cisco
> products, obtaining assistance with security incidents, and
> registering to receive security information from Cisco, is available
> on Cisco's worldwide website at
>
> ility_poli
> cy.html
>
> This includes instructions for press inquiries regarding
> Cisco security
> notices. All Cisco security advisories are available at
>
>
>
>
> Regards,
> Randy
>
> Randy Ivener
> Product Security Incident Response Team (PSIRT)
> Cisco Systems, Inc.
> rivener@xxxxxxxxx
>
>
> -----BEGIN PGP SIGNATURE-----
> Version: PGP 8.1
>
> iQA/AwUBQ4NEmG4/EyDEWh8IEQJ39gCdEAOan25rIq/sneCgawAWnuhbYSEAoN8q
> tXrEk2ydhM/6vW2up04x1VAQ
> =mZg7
> -----END PGP SIGNATURE-----
>
>
> ------------------------------
>
> Message: 2
> Date: Tue, 22 Nov 2005 08:31:20 -0800
> From: "Randy Ivener \(rivener\)" <rivener@xxxxxxxxx>
> Subject: [Full-disclosure] Cisco PIX TCP Connection Prevention
> To: <full-disclosure@xxxxxxxxxxxxxxxxx>
> Message-ID:
>
> <6E7590A4D7F8244BA8ECE4FEC6782F650121CECB@xxxxxxxxxxxxxxxxxxxxxxxxxx>
> Content-Type: text/plain; charset="us-ascii"
>
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Cisco Response
> ==============
>
> This is Cisco PSIRT's response to the statements made by Arhont Ltd.-
> Information Security in its message: [Full-disclosure] Cisco PIX TCP
> Connection Prevention, posted on November 22, 2005.
>
> The original email is available at:
>
> er/038971.
> html
>
> Attached is a cleartext, PGP signed version of this same email.
>
> This issue is being tracked by two Cisco Bug IDs:
>
>
> * CSCsc14915 -- PIX 6.3 Spoofed TCP SYN packets can block
> legitimate TCP connections
>
> This Bug ID tracks the issue for PIX software version 6.3
> and older. This DDTS is under investigation and while not
> resolved there are workarounds available to mitigate the
> issue.
>
> * CSCsc16014 -- PIX 7.0 Spoofed TCP SYN packets can block
> legitimate TCP connections
>
> This Bug ID tracks the issue for PIX/ASA software version
> 7.0. This DDTS is under investigation and while not
> resolved additional mitigations and workarounds exist
> to limit or eliminate the issue.
>
>
> We would like to thank Arhont Ltd.- Information Security for
> reporting this issue to us.
>
> We greatly appreciate the opportunity to work with researchers on
> security vulnerabilities, and welcome the opportunity to review and
> assist in product reports.
>
>
> Additional Information
> ======================
>
> PIX 6.3
> =======
>
> * CSCsc14915 -- PIX 6.3 Spoofed TCP SYN packets can block
> legitimate TCP connections
>
> This issue affects PIX software version 6.3 and older. The Release
> Note Enclosure for this Bug ID states:
>
> Symptom
> +------
> TCP connections through the firewall may be silently blocked.
>
>
> Conditions
> +---------
>
> By sending a TCP SYN packet with an incorrect checksum through a PIX
> firewall, the PIX will block new TCP connections using the same
> source and destination TCP ports and IP addresses. Connections will
> remain blocked for approximately two minutes after which connections
> will be allowed. This behavior may be seen on all firewall interfaces
> but can be expected to have the most impact on TCP connections
> originating from higher security level interfaces to lower security
> level interfaces.
>
> Since the spoofed packets have an incorrect checksum, they are
> silently discarded by the destination and the firewall will not see a
> RST packet from either the destination or the legitimate source and
> will hold the embryonic connection open until the embryonic
> connection timeout which is 2 minutes by default.
>
> The root cause is due to the spoofed packet creating an embryonic
> connection which sets up the TCP sliding window. A valid packet from
> a real host using the same connection as the spoofed packet sends a
> SYN over the same connection. The sequence number of the valid
> packet is out-of-window and rejected by the firewall's TCP sequence
> number check. Any subsequent retransmissions of the valid packet are
> also out-of-window and are rejected by TCP sequence number check.
>
> Other spoofed TCP SYN packets that create embryonic connections can
> also cause this behavior, blocking legitimate TCP connections until
> the embryonic connection times out.
>
>
> Workarounds
> +----------
>
> Issuing the commands "clear xlate" or "clear local-host <ip address
> on the higher security level interface>" will allow the firewall to
> pass connections again.
>
> TCP connections discarded because of this issue can be verified by
> enabling "debug fixup tcp". 'Out of Window' drops will then generate
> messages that begin with "tcpseq: discard old packet". Debug messages
> may impact firewall performance and should be tested before being
> enabled in a production environment.
>
> For discarded TCP connections originating from lower security level
> interfaces to higher security level interfaces, TCP Intercept can be
> configured on "STATIC" commands by setting the "emb_limit" to 1. This
> results in the PIX proxying all connection attempts after the first
> connection. The PIX will create and send the TCP SYN,ACK from the
> destination to the original source. Since the original TCP SYN packet
> was spoofed, the source IP address will not be tracking the TCP
> connection and it will send a TCP RST to the PIX. The PIX will then
> close the connection originating from the TCP SYN packet with the
> incorrect checksum. TCP Intercept may impact firewall performance and
> should be tested before being enabled in a production environment.
>
>
> Further Problem Description
> +--------------------------
>
> PIX software version 6.3 does not verify the TCP checksum of packets
> transiting through the firewall.
>
> Because the PIX does not verify the TCP checksum, the malformed TCP
> packet is allowed through the firewall in a half-opened, embryonic
> state.
>
> The destination host discards the received malformed segments.
> Because the firewall does not see a return segment from the
> destination host it holds the half-open TCP connection open until the
> embryonic timeout which is set to two minutes for PIX 6.3 and earlier
> software.
>
> Because the firewall is holding a connection open, any additional
> packets with the same protocol, IP addresses, and ports will be
> treated as part of the existing half-open connection. In this case, a
> legitimate SYN packet following the malformed SYN will be discarded
> because it is outside of the window of acceptable sequence numbers
> established by the malformed packet.
>
> For information on configuring the emb_limit as part of the "STATIC"
> command in PIX software version 6.3 refer to:
>
> STATIC
>
> sw/v_63/cm
> dref/s.htm#wp1026694
>
>
>
> PIX/ASA 7.0
> ===========
>
> * CSCsc16014 -- PIX 7.0 Spoofed TCP SYN packets can block
> legitimate TCP connections
>
> This issue affects PIX/ASA software version 7.0. Additional
> mitigations and workarounds to limit or eliminate the issue. The
> Release Note Enclosure for this Bug ID states:
>
>
> Symptom
> +------
>
> TCP connections through the firewall may be silently blocked.
>
>
> Conditions
> +---------
>
> By sending a TCP SYN packet with an invalid checksum through a PIX
> firewall, the PIX will block new TCP connections using the same
> source and destination TCP ports and IP addresses. Connections will
> remain blocked until the embryonic connection timeout which is 30
> seconds by default. This behavior may be seen on all firewall
> interfaces but can be expected to have the most impact on TCP
> connections originating from higher security level interfaces to
> lower security level interfaces.
>
> Since the spoofed packets have an invalid checksum, they are silently
> discarded by the destination and the firewall will not see a RST
> packet from either the destination or the legitimate source and will
> hold the embryonic connection open until the embryonic connection
> timeout which is 30 seconds by default.
>
> The root cause is due to the spoofed packet creating an embryonic
> connection which sets up the TCP sliding window. A valid packet from
> a real host using the same connection as the spoofed packet sends a
> SYN over the same connection. The sequence number of the valid
> packet is out-of-window and rejected by the firewall's TCP sequence
> number check. Any subsequent retransmissions of the valid packet are
> also out-of-window and are rejected by TCP sequence number check.
>
> Other spoofed TCP SYN packets that create embryonic connections can
> also cause this behavior, blocking legitimate TCP connections until
> the embryonic connection times out.
>
> This behavior can be verified by issuing the command: "show asp drop"
>
> The counter for "TCP RST/SYN in window" or "TCP SEQ in SYN/SYNACK
> invalid" should increment for every packet dropped in this manner.
>
>
> Workarounds
> +----------
>
> Several workarounds exist for this issue.
>
> 1. Issuing the commands "clear xlate" or "clear local-host <ip
> address on the higher security level interface>" will allow the
> firewall to pass connections again.
>
>
> 2. The default TCP embryonic connection timeout is 30 seconds. This
> default can also be modified which further mitigates the issue. This
> workaround should be effective regardless of the cause of the issue.
>
> This configuration example sets the TCP embryonic connection timeout
> to 10 seconds for the default "global_policy" policy-map:
>
> access-list tcp_inspection extended permit tcp any any
> access-list tcp_inspection extended deny ip any any
>
> class-map my_inspection_tcp
> match access-list tcp_inspection
>
> policy-map global_policy
> class my_inspection_tcp
> set connection timeout embryonic 0:00:10
>
> service-policy global_policy global
>
>
> 3. TCP Intercept can be configured to allow the PIX to proxy all TCP
> connection attempts originated from behind any firewall interface
> after the first connection. PIX will create and send the TCP SYN,ACK
> from the destination to the original source. Since the original TCP
> SYN packet was spoofed, the source IP address will not be tracking
> the TCP connection and it will send a TCP RST to the PIX. The PIX
> will then close the connection originating from the TCP SYN packet
> with the invalid checksum. This workaround should be effective
> regardless of the cause of the issue.
>
> This example proxies all TCP connection attempts originated from any
> firewall interface
> after the first connection for the default "global_policy"
> policy-map:
>
> access-list tcp_inspection extended permit tcp any any
> access-list tcp_inspection extended deny ip any any
>
> class-map my_inspection_tcp
> match access-list tcp_inspection
>
> policy-map global_policy
> class my_inspection_tcp
> set connection embryonic-conn-max 1
>
> service-policy global_policy global
>
>
> 4. When invalid checksums are the cause of this issue, PIX/ASA
> software version 7.0 can be configured to verify TCP checksums which
> will eliminate the impact. Verifying TCP checksums may impact
> firewall performance and should be tested before being enabled in a
> production environment.
>
> This example verifies TCP packet checksums for the default
> "global_policy" policy-map:
>
> tcp-map verify-chksum
> checksum-verification
>
> access-list tcp_inspection extended permit tcp any any
> access-list tcp_inspection extended deny ip any any
>
> class-map my_inspection_tcp
> match access-list tcp_inspection
>
> policy-map global_policy
> class my_inspection_tcp
> set connection advanced-options verify-chksum
>
> service-policy global_policy global
>
>
>
>
> Cisco Security Procedures
> =========================
>
> Complete information on reporting security vulnerabilities in Cisco
> products, obtaining assistance with security incidents, and
> registering to receive security information from Cisco, is available
> on Cisco's worldwide website at
>
> ility_poli
> cy.html
>
> This includes instructions for press inquiries regarding
> Cisco security
> notices. All Cisco security advisories are available at
>
>
>
>
> Regards,
> Randy
>
> Randy Ivener
> Product Security Incident Response Team (PSIRT)
> Cisco Systems, Inc.
> rivener@xxxxxxxxx
>
>
>
> *** END PGP VERIFIED MESSAGE ***
>
> -----BEGIN PGP SIGNATURE-----
> Version: PGP 8.1
>
> iQA/AwUBQ4NHtW4/EyDEWh8IEQJjMwCcCXBG7OPvZI2mQ10I9pfrkW7k+4AAoJFw
> iBoy1Nw1V2wQwcVEhyf4dzui
> =U9RU
> -----END PGP SIGNATURE-----
> -------------- next part --------------
> A non-text attachment was scrubbed...
> Name: cisco-full-disclosure-pix-tcp-connection-prevention.txt.asc
> Type: application/octet-stream
> Size: 11258 bytes
> Desc: cisco-full-disclosure-pix-tcp-connection-prevention.txt.asc
> Url :
>
> /20051122/4b025302/cisco-full-disclosure-pix-tcp-connection-pr
> evention.txt-0001.obj
>
>
