PF Scrub

2004-03-03 Thread Mark Bojara 
Hello All,

Just a quick question. I am doing scrub on my upstream OpenBSD server.
Will this work as a temporary workaround for this security flaw (below)
in FreeBSD?

Regards
Mark


-Forwarded Message-
From: FreeBSD Security Advisories [EMAIL PROTECTED]
To: FreeBSD Security Advisories [EMAIL PROTECTED]
Subject: FreeBSD Security Advisory FreeBSD-SA-04:04.tcp
Date: Tue, 02 Mar 2004 11:55:44 -0800

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

=
FreeBSD-SA-04:04.tcp  Security Advisory
  The FreeBSD Project

Topic:  many out-of-sequence TCP packets denial-of-service

Category:   core
Module: kernel
Announced:  2004-03-02
Credits:iDEFENSE
Affects:All FreeBSD releases
Corrected:  2004-03-02 17:19:18 UTC (RELENG_4)
2004-03-02 17:24:46 UTC (RELENG_5_2, 5.2.1-RELEASE-p1)
2004-03-02 17:26:33 UTC (RELENG_4_9, 4.9-RELEASE-p3)
2004-03-02 17:27:47 UTC (RELENG_4_8, 4.8-RELEASE-p16)
CVE Name:   CAN-2004-0171
FreeBSD only:   NO

I.   Background

The Transmission Control Protocol (TCP) of the TCP/IP protocol suite
provides a connection-oriented, reliable, sequence-preserving data
stream service.  When network packets making up a TCP stream (``TCP
segments'') are received out-of-sequence, they are maintained in a
reassembly queue by the destination system until they can be re-ordered
and re-assembled.

II.  Problem Description

FreeBSD does not limit the number of TCP segments that may be held in a
reassembly queue.

III. Impact

A remote attacker may conduct a low-bandwidth denial-of-service attack
against a machine providing services based on TCP (there are many such
services, including HTTP, SMTP, and FTP).  By sending many
out-of-sequence TCP segments, the attacker can cause the target machine
to consume all available memory buffers (``mbufs''), likely leading to
a system crash.

IV.  Workaround

It may be possible to mitigate some denial-of-service attacks by
implementing timeouts at the application level.

V.   Solution

Do one of the following:

1) Upgrade your vulnerable system to 4-STABLE, or to the RELENG_5_2,
RELENG_4_9, or RELENG_4_8 security branch dated after the correction
date.

OR

2) Patch your present system:

The following patch has been verified to apply to FreeBSD 4.x and 5.x
systems.

a) Download the relevant patch from the location below, and verify the
detached PGP signature using your PGP utility.

[FreeBSD 5.2]
# fetch ftp://ftp.FreeBSD.org/pub/FreeBSD/CERT/patches/SA-04:04/tcp52.patch
# fetch ftp://ftp.FreeBSD.org/pub/FreeBSD/CERT/patches/SA-04:04/tcp52.patch.asc

[FreeBSD 4.8, 4.9]
# fetch ftp://ftp.FreeBSD.org/pub/FreeBSD/CERT/patches/SA-04:04/tcp47.patch
# fetch ftp://ftp.FreeBSD.org/pub/FreeBSD/CERT/patches/SA-04:04/tcp47.patch.asc

b) Apply the patch.

# cd /usr/src
# patch  /path/to/patch

c) Recompile your kernel as described in
URL:http://www.freebsd.org/handbook/kernelconfig.html and reboot the
system.

VI.  Correction details

The following list contains the revision numbers of each file that was
corrected in FreeBSD.

Branch   Revision
  Path
- -
RELENG_4
  src/UPDATING  1.73.2.90
  src/sys/conf/newvers.sh   1.44.2.33
  src/sys/netinet/tcp_input.c  1.107.2.40
  src/sys/netinet/tcp_subr.c1.73.2.33
  src/sys/netinet/tcp_var.h 1.56.2.15
RELENG_5_2
  src/UPDATING  1.282.2.9
  src/sys/conf/newvers.sh1.56.2.8
  src/sys/netinet/tcp_input.c   1.217.2.2
  src/sys/netinet/tcp_subr.c1.169.2.4
  src/sys/netinet/tcp_var.h  1.93.2.2
RELENG_4_9
  src/UPDATING  1.73.2.89.2.4
  src/sys/conf/newvers.sh   1.44.2.32.2.4
  src/sys/netinet/tcp_input.c  1.107.2.38.2.1
  src/sys/netinet/tcp_subr.c1.73.2.31.4.1
  src/sys/netinet/tcp_var.h 1.56.2.13.4.1
RELENG_4_8
  src/UPDATING 1.73.2.80.2.19
  src/sys/conf/newvers.sh  1.44.2.29.2.17
  src/sys/netinet/tcp_input.c  1.107.2.37.2.1
  src/sys/netinet/tcp_subr.c1.73.2.31.2.1
  src/sys/netinet/tcp_var.h 1.56.2.13.2.1
-

Re: PF Scrub

2004-03-03 Thread Daniel Hartmeier 
On Wed, Mar 03, 2004 at 11:40:03AM +0200, Mark Bojara wrote:

 Just a quick question. I am doing scrub on my upstream OpenBSD server.
 Will this work as a temporary workaround for this security flaw (below)
 in FreeBSD?

No, scrub does IP reassembly (assembling IP fragments into complete IP
packets). But the problem you refer to is about out-of-order TCP
segments. It's a somewhat similar scheme (TCP reassembly does something
similar to IP reassembly), but on a different level.

I think doing this in pf scrub for TCP segments is still on the todo
list (or once was, at least) ;)

Daniel

Re: PF Scrub

2004-03-03 Thread Daniel Hartmeier 
It might be worth adding that the traffic exploiting that problem is not
invalid in any sense. TCP segments can arrive out-of-order in legitimate
usage, too. For instance, individual TCP packets of one connection can
take different paths to your peer, so a higher fragment may very well
arrive before a lower one. If that was not expected, there would be no
need for TCP reassembly at all.

So, reassembling TCP segments is needed, unless you're willing to break
perfectly legitimate connections. But an attacker should not be able to
grow the reassembly queue up to the point where you crash because you
run out of memory. Finding a good strategy to decide what queue entries
to drop at what point is not trivial. I think we'll wait and see what
strategies work best in the TCP/IP stack, and use that experience if/when
implementing TCP reassembly in pf scrub.

Daniel