Date: Wed, 29 Apr 2015 18:07:08 -0400 From: Mike Tancsa <mike@sentex.net> To: "freebsd-security@freebsd.org" <freebsd-security@freebsd.org> Subject: SA-14:19 (Denial of Service in TCP packet processing) and jails issue ? Message-ID: <5541560C.5020004@sentex.net>
next in thread | raw e-mail | index | archive | help
While running a Qualys scan against one of our RELENG_9 boxes (9.3-STABLE #16 r281494), it came up complaining about the SA below as an issue still ? https://www.freebsd.org/security/advisories/FreeBSD-SA-14:19.tcp.asc The server should have this fix in place no ? # svn info /usr/src Path: /usr/src Working Copy Root Path: /usr/src URL: svn://svn.freebsd.org/base/stable/9 Relative URL: ^/stable/9 Repository Root: svn://svn.freebsd.org/base Repository UUID: ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f Revision: 281494 Node Kind: directory Schedule: normal Last Changed Author: jkim Last Changed Rev: 281389 Last Changed Date: 2015-04-10 21:17:19 -0400 (Fri, 10 Apr 2015) Also, we have pf in place with the first rule being #block everything by default coming in block in log all and then explicitly letting in the ports we want, with keep state The IP being scanned is in a jail. If I run the scan to an IP not associated with the jail, the scan does not complain. Its only on the jailed IP that the scan flags as problematic for this vulnerability. Looking at the src of tcp_input.c, I see todrop = tp->rcv_nxt - th->th_seq; if (todrop > 0) { if (thflags & TH_SYN) { thflags &= ~TH_SYN; th->th_seq++; if (th->th_urp > 1) th->th_urp--; else thflags &= ~TH_URG; todrop--; } so the code path looks right based on the commit in https://lists.freebsd.org/pipermail/svn-src-stable-9/2014-September/007198.html If this is a false positive, how can I be sure thats the case ? I have pcaps of the scan both against the jailed IP (with the scan saying its vulnerable) and against an IP not associated with the jail, saying its not an issue. QID: 82054 Category: TCP/IP CVE ID: CVE-2004-0230 Vendor Reference - Bugtraq ID: 10183 Service Modified: 02/02/2010 User Modified: - Edited: No PCI Vuln: No Ticket State: TCP provides stateful communications between hosts on a network. TCP sessions are established by a three-way handshake and use random 32-bit sequence and acknowledgement numbers to ensure the validity of traffic. A vulnerability was reported that may permit TCP sequence numbers to be more easily approximated by remote attackers. This issue affects products released by multiple vendors. The cause of the vulnerability is that affected implementations will accept TCP sequence numbers within a certain range, known as the acknowledgement range, of the expected sequence number for a packet in the session. This is determined by the TCP window size, which is negotiated during the three-way handshake for the session. Larger TCP window sizes may be set to allow for more throughput, but the larger the TCP window size, the more probable it is to guess a TCP sequence number that falls within an acceptable range. It was initially thought that guessing an acceptable sequence number was relatively difficult for most implementations given random distribution, making this type of attack impractical. However, some implementations may make it easier to successfully approximate an acceptable TCP sequence number, making these attacks possible with a number of protocols and implementations. This is further compounded by the fact that some implementations may support the use of the TCP Window Scale Option, as described in RFC 1323, to extend the TCP window size to a maximum value of 1 billion. This vulnerability will permit a remote attacker to inject a SYN or RST packet into the session, causing it to be reset and effectively allowing for denial of service attacks. An attacker would exploit this issue by sending a packet to a receiving implementation with an approximated sequence number and a forged source IP address and TCP port. There are a few factors that may present viable target implementations, such as those which depend on long-lived TCP connections, those that have known or easily guessed IP address endpoints and those implementations with easily guessed TCP source ports. It has been noted that Border Gateway Protocol (BGP) is reported to be particularly vulnerable to this type of attack, due to the use of long-lived TCP sessions and the possibility that some implementations may use the TCP Window Scale Option. As a result, this issue is likely to affect a number of routing platforms. Another factor to consider is the relative difficulty of injecting packets into TCP sessions, as a number of receiving implementations will reassemble packets in order, dropping any duplicates. This may make some implementations more resistant to attacks than others. It should be noted that while a number of vendors have confirmed this issue in various products, investigations are ongoing and it is likely that many other vendors and products will turn out to be vulnerable as the issue is investigated further. -- ------------------- Mike Tancsa, tel +1 519 651 3400 Sentex Communications, mike@sentex.net Providing Internet services since 1994 www.sentex.net Cambridge, Ontario Canada http://www.tancsa.com/
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?5541560C.5020004>