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>