Mike Tancsa
2015-Apr-29 22:07 UTC
SA-14:19 (Denial of Service in TCP packet processing) and jails issue ?
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 at sentex.net
Providing Internet services since 1994 www.sentex.net
Cambridge, Ontario Canada http://www.tancsa.com/
Mike Tancsa
2015-May-04 21:28 UTC
SA-14:19 (Denial of Service in TCP packet processing) and jails issue ?
On 4/29/2015 6:07 PM, Mike Tancsa wrote:> > 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. > > 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. >Anyone have any have any ideas what can be done to mitigate this risk if its real, or if its a false positive ? To further clarify/describe my test environment, this is a RELENG_9 box I am testing against. I have a number of IPs aliased to lo0 associated with jails. If I run the Qualsys scan against an IP on this box that is not associated with a jail, it passes the test for SA-14:19. If I run the test against an IP associated with the jail, it fails the test. e.g. IP 192.168.1.1 is aliased to lo0 and associated with jail1.sentex.ca. If I run the free qualsys scan against jail1.sentex.ca, the test fails. If I stop the jail, and run the qualsys scan against the same IP, which is now just an aliased IP on the host machine, it passes the test. I have the pcaps, but I am not sure exactly what I am looking for in the data. The test just says it confirmed the vulnerability with the following 2 tests, Tested on port 22 with an injected SYN/RST offset by 16 bytes. Tested on port 25 with an injected SYN/RST offset by 16 bytes. What is it about the jail that might be causing either this issue to resurface, or give a false positive that its an issue ? ---Mike -- ------------------- Mike Tancsa, tel +1 519 651 3400 Sentex Communications, mike at sentex.net Providing Internet services since 1994 www.sentex.net Cambridge, Ontario Canada http://www.tancsa.com/