From owner-freebsd-security@FreeBSD.ORG Tue Apr 28 03:52:10 2015 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 9FEF242B for ; Tue, 28 Apr 2015 03:52:10 +0000 (UTC) Received: from outgoing.tristatelogic.com (segfault.tristatelogic.com [69.62.255.118]) by mx1.freebsd.org (Postfix) with ESMTP id 823891AF7 for ; Tue, 28 Apr 2015 03:52:09 +0000 (UTC) Received: from segfault-nmh-helo.tristatelogic.com (localhost [127.0.0.1]) by segfault.tristatelogic.com (Postfix) with ESMTP id 4F4203ADE4 for ; Mon, 27 Apr 2015 20:52:09 -0700 (PDT) From: "Ronald F. Guilmette" To: freebsd-security@freebsd.org Subject: Re: Logging TCP anomalies In-Reply-To: Date: Mon, 27 Apr 2015 20:52:09 -0700 Message-ID: <46186.1430193129@server1.tristatelogic.com> X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Apr 2015 03:52:10 -0000 In message , Charles Swiger wrote: >On Apr 27, 2015, at 3:12 PM, Ronald F. Guilmette >wrote: >> As I understand it, (verbatim) duplicate packets can sometimes arrive at >> an endpoint due simply to network anomalies. However as I understand it, >> those will typically have identical lengths and payloads. > >Typically. But you can also have multipath transit where one path has a different >MTU than the other: a packet can get dup'ed and have one copy then get fragmented >when flowing through that different route. So, the question becomes: How common is THAT scenario, in practice? And if it is reasonably uncommon, then might it still be worthwhile to at least _log_ cases where two back-to-back TCP packets arrive in succession, where both have an identical squence number, but where they have different lengths and/or checksums (thus indicating possible or perhaps even probably funny business)? Also, although I don't even pretend to be a expert with respect to either TCP or the software stacks that implement it, I must nontheless ask if the exact kind of check I proposed could perhaps be implemented at some level of the protocol stack which is subsequent to fragmented packet reassembly (thereby eliminating as a problem the specific scenario you raised). >>If I read that news article correctly, then the spoofed packets at issue >>will have the >>same sequence numbers as legit ones, but different lengths and/or >>payloads. >Yes. One can also go to town with mechanisms like having the inner protocol >checksum be invalid-- I'm sorry, but I do not grasp what it is that you are driving at, exactly. May I ask you, with respect, if you could state the issue in a different way that I might understand? >> It seems simple enough to detect instances when two packets with the >> exact same sequence number but different lengths arrive at a given >> endpoint in immediate proximity (in time). > >It's much harder to tell whether that happens legitimately, is due to a bug >with the network stack, TSO, etc or is someone playing games with a covert >channel. While I am quite certainly not nearly enough of an expert to be able to in any way take issue with what you've just said, I ceratinly would like to ask you to elaborate further on these scenarios... and whether they atre likely to be at all common, in practice... if you wouldn't mind. >>> For that matter, an attacker could try to spoof >>> legit connections and your countermeasure would presumably zap the >>> legit connection. We seem to be in agreement that the possibility of a nefarious attacker, with evil intent, being able to successfully pull off exactly such spoofing is predicated upon his having direct access to the wire... in which case I personally feel and believe that the victim may have vastly more serious problems to worry about than just abruptly dropped TCP connections. Regards, rfg