From owner-freebsd-security Fri Nov 21 09:10:27 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id JAA22310 for security-outgoing; Fri, 21 Nov 1997 09:10:27 -0800 (PST) (envelope-from owner-freebsd-security) Received: from biggusdiskus.flyingfox.com (biggusdiskus.flyingfox.com [206.14.52.27]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id JAA22294 for ; Fri, 21 Nov 1997 09:10:23 -0800 (PST) (envelope-from jas@flyingfox.com) Received: (from jas@localhost) by biggusdiskus.flyingfox.com (8.8.5/8.8.5) id JAA04036; Fri, 21 Nov 1997 09:11:25 -0800 (PST) Date: Fri, 21 Nov 1997 09:11:25 -0800 (PST) From: Jim Shankland Message-Id: <199711211711.JAA04036@biggusdiskus.flyingfox.com> To: Don.Lewis@tsc.tdk.com Subject: Re: new TCP/IP bug in win95 (fwd) Cc: security@freebsd.org Sender: owner-freebsd-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Hmm, I'm not sure I agree that your fix is optimal for this bug, Don. Seems like you're relying on the ACK field being out of range to drop the packet that the victim machine itself generated. Apart from generating an extra packet (the bogus response that the victim sends in response to the original, forged SYN), it also seems that if the attacker can guess the right sequence number, it can circumvent your fix. Granted, that's much harder -- and more platform-variable -- than the exploit that's been posted. The essence of the attack lies in engineering a TCP connection in which (src-ip, src-port) is equal to (dst-ip, dst-port); the fact that the ACK value in the second packet is out of range seems like a sort of side effect. I can't think of any case in which it would be legal or desirable to have a TCP connection with (src-ip, src-port) equal to (dst-ip, dst-port); so why not just reject such a connection attempt out of hand in the TCPS_LISTEN state? Jim Shankland Flying Fox Computer Systems, Inc.