Skip site navigation (1)Skip section navigation (2)
Date:      Sun, 17 Dec 2000 18:30:16 +0100
From:      Jesper Skriver <jesper@skriver.dk>
To:        "Louis A. Mamakos" <louie@TransSys.COM>
Cc:        Kris Kennaway <kris@FreeBSD.ORG>, Poul-Henning Kamp <phk@FreeBSD.ORG>, cvs-committers@FreeBSD.ORG, cvs-all@FreeBSD.ORG, security-officer@FreeBSD.ORG
Subject:   Re: cvs commit: src/sys/netinet ip_icmp.c tcp_subr.c tcp_var.h
Message-ID:  <20001217183016.C34282@skriver.dk>
In-Reply-To: <20001217182056.B34282@skriver.dk>; from jesper@skriver.dk on Sun, Dec 17, 2000 at 06:20:56PM %2B0100
References:  <200012161942.eBGJg7j93654@freefall.freebsd.org> <20001217012007.A18038@citusc.usc.edu> <200012171529.eBHFT4512582@whizzo.transsys.com> <20001217182056.B34282@skriver.dk>

next in thread | previous in thread | raw e-mail | index | archive | help
On Sun, Dec 17, 2000 at 06:20:56PM +0100, Jesper Skriver wrote:
> On Sun, Dec 17, 2000 at 10:29:04AM -0500, Louis A. Mamakos wrote:
> > > On Sat, Dec 16, 2000 at 11:42:07AM -0800, Poul-Henning Kamp wrote:
> > > > phk         2000/12/16 11:42:07 PST
> > > > 
> > > >   Modified files:
> > > >     sys/netinet          ip_icmp.c tcp_subr.c tcp_var.h 
> > > >   Log:
> > > >   We currently does not react to ICMP administratively prohibited
> > > >   messages send by routers when they deny our traffic, this causes
> > > >   a timeout when trying to connect to TCP ports/services on a remote
> > > >   host, which is blocked by routers or firewalls.
> > > 
> > > This sounds like a security hole since ICMP messages don't have a TCP
> > > sequence number meaning they can be trivially spoofed - am I wrong?
> > 
> > The Destination Unreachable ICMP message should include a copy of the
> > IP header plus 20 bytes of payload (TCP segment header) which you
> > could use to validate it.  I only glanced briefly at the patch, and don't
> > know if that was being done or not.
> 
> It doesn't, from what I could read, we only get the IP header, so what
> was committed only looks at the protocol (make sure it's TCP) and source/
> destination ip address, and zap's all matching TCP sessions in SYN-SENT 
> state.
> 
> > At that point, the situation is essentially the same as a RST-based
> > attack and trying to predict TCP sequence numbers.
> 
> Agree, will look more at this, and see if we can the tcp source and
> destination port numbers.

A sniffer trace gives me the IP header + 8 bytes. The first 8 bytes of
the TCP header is source and destination ports + sequence number.

Now, I need to find a way to decode these 8 bytes, and find the matching
sessions, and only zap those.

I'll look more at this, but I probably won't have anything working until
later this week, as I have a few things I need to get done first.

As the code is disabled by default, I don't think this is a major
problem ?

/Jesper

-- 
Jesper Skriver, jesper(at)skriver(dot)dk  -  CCIE #5456
Work:    Network manager @ AS3292 (Tele Danmark DataNetworks)
Private: Geek            @ AS2109 (A much smaller network ;-)

One Unix to rule them all, One Resolver to find them,
One IP to bring them all and in the zone to bind them.


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe cvs-all" in the body of the message




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20001217183016.C34282>