From owner-freebsd-security@FreeBSD.ORG Mon Apr 27 08:41:19 2015 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 2DD7EC9F for ; Mon, 27 Apr 2015 08:41:19 +0000 (UTC) Received: from mx1.riseup.net (mx1.riseup.net [198.252.153.129]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "*.riseup.net", Issuer "COMODO RSA Domain Validation Secure Server CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 0F3961384 for ; Mon, 27 Apr 2015 08:41:18 +0000 (UTC) Received: from berryeater.riseup.net (berryeater-pn.riseup.net [10.0.1.120]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.riseup.net", Issuer "COMODO RSA Domain Validation Secure Server CA" (verified OK)) by mx1.riseup.net (Postfix) with ESMTPS id 6E13340E87; Mon, 27 Apr 2015 01:34:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=riseup.net; s=squak; t=1430123683; bh=OW/W4FoMr3EpRD/DY3RZ0cd3LeYMnobRVjLL6WCTd9g=; h=Date:From:To:CC:Subject:From; b=TzFTtyRNQBsevSqESxYLPL8qDs9iWp454Gt75P52ebK4n1deb3deV3URHmkCrZdaO OWTY7eVMm4YOfGKq2B4SfyNOAKbsJmbruj3SqOCsOtdCd+GB0S4WKBEq7+VpYJgxL+ uewadmXsD+E9i2lBTSS1obywvQelUGhn3rFh4L/g= Received: from [127.0.0.1] (localhost [127.0.0.1]) (Authenticated sender: pkubaj) with ESMTPSA id 9CA1240E86 Message-ID: <553DF49E.3020502@riseup.net> Date: Mon, 27 Apr 2015 10:34:38 +0200 From: Piotr Kubaj User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: freebsd-security@freebsd.org CC: venture37@gmail.com Subject: Re: base/release/10.1.0/contrib/file vulnerabilities? Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="uECupdQeNGdn6f8JjMXk6Ij8CXu3lj6TW" X-Virus-Scanned: clamav-milter 0.98.6 at mx1 X-Virus-Status: Clean X-Mailman-Approved-At: Mon, 27 Apr 2015 11:30:38 +0000 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: Mon, 27 Apr 2015 08:41:19 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --uECupdQeNGdn6f8JjMXk6Ij8CXu3lj6TW Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi, I wrote about this vulnerability in January: https://lists.freebsd.org/pipermail/freebsd-security/2015-January/008115.= html There were only patches for stable. --uECupdQeNGdn6f8JjMXk6Ij8CXu3lj6TW Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCAAGBQJVPfSfAAoJEC9nKukRsfY+GZkP/34pt/mJ1rpsUNUmCFzVGszV Y6bPWUZdv6x7YkJc4OBT2V9dfnOEmKlDZ1swqMRqc+MgDGFOumcHMM328Hq18Ism zljAfX5ugDpPsU1iiHnmCOKiNTN3r4YFCAtl76dLZ8UaxA/5T/ulDFbiyZJuuCbk Y08TjfFt5g3YayVRg6hN0Yo9tXXB5Y/D57ql0cLPcw2B6UsrCsvwzb9JEMRRu2S/ 0t6A4SfJmtQcJeRNl7cEsq56bqqc3UOFt0Bzng4xkYhMwWldjHRdAd+nvoaPyqKt PEOr92vQIxNKBZl8Ncz/jCPNkgXdlaLqOew9975qNbi1DfBczK8593M8p1cQ2hwu vT14W+ihYxV7EiFI2x3QnYeOAOy2Djx2h44h/kLHVTcdC+O93Jvl7U3Z1IduOvC7 dgxGI/Wv0IRzCuaM7abNZMc7XH0o2nrm8xMWvgpLPDchBGkNQmqjynmufo1vVyCv cZPdHuHWHX7Uyl9x2wyYbrsD74aG+C3hUO1uHR2af35Y1qYNlpzkll5VKqqQQBKH qpe9qsw8ie4Yy4bLcQLnbaCf+Po5IOBQgcBdz73tS13ttdXFBtCgoJ4fcZlOxcLR X0xlZLS1svTdR/kNoknDiDtzM7mmQIiciFepog1hd03wFmuOdFGpzbVFqpEJw5m1 ImHRWoEDJzW/cPxkGVCN =UPYg -----END PGP SIGNATURE----- --uECupdQeNGdn6f8JjMXk6Ij8CXu3lj6TW-- From owner-freebsd-security@FreeBSD.ORG Mon Apr 27 18:46:43 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 ADE7B32D for ; Mon, 27 Apr 2015 18:46:43 +0000 (UTC) Received: from outgoing.tristatelogic.com (segfault.tristatelogic.com [69.62.255.118]) by mx1.freebsd.org (Postfix) with ESMTP id 98FD61BC2 for ; Mon, 27 Apr 2015 18:46:43 +0000 (UTC) Received: from segfault-nmh-helo.tristatelogic.com (localhost [127.0.0.1]) by segfault.tristatelogic.com (Postfix) with ESMTP id 69ADE3ADE4 for ; Mon, 27 Apr 2015 11:37:22 -0700 (PDT) From: "Ronald F. Guilmette" To: freebsd-security@freebsd.org Subject: Logging TCP anomalies Date: Mon, 27 Apr 2015 11:37:22 -0700 Message-ID: <43372.1430159842@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: Mon, 27 Apr 2015 18:46:43 -0000 I just now read the following TheRegister news article about detection of "Quantum Insert" funny business: http://www.theregister.co.uk/2015/04/23/detecting_nsa_style_hacking_tool_unsheathed/ I am prompted to ask here whether or not FreeBSD performs any sort of logging of instances when "duplicate TCP packets but with different payloads" occurs, and/or whether FreeBSD provides any options which, for example, might automagically trigger a close of the relevant TCP connection when and if such an event is detected. (Connection close seems to me to be one possible mitigation strategy, even if it might be viewed as rather ham-fisted by some.) From owner-freebsd-security@FreeBSD.ORG Mon Apr 27 19:49:25 2015 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 7EEDD6EA for ; Mon, 27 Apr 2015 19:49:25 +0000 (UTC) Received: from be-well.ilk.org (be-well.ilk.org [23.30.133.173]) by mx1.freebsd.org (Postfix) with ESMTP id 595601325 for ; Mon, 27 Apr 2015 19:49:25 +0000 (UTC) Received: from lowell-desk.lan (lowell-desk.lan [172.30.250.41]) by be-well.ilk.org (Postfix) with ESMTP id 027E533C24; Mon, 27 Apr 2015 15:49:13 -0400 (EDT) Received: by lowell-desk.lan (Postfix, from userid 1147) id 48AFC39843; Mon, 27 Apr 2015 15:49:11 -0400 (EDT) From: Lowell Gilbert To: "Ronald F. Guilmette" Cc: freebsd-security@freebsd.org Subject: Re: Logging TCP anomalies References: <43372.1430159842@server1.tristatelogic.com> Date: Mon, 27 Apr 2015 15:49:11 -0400 In-Reply-To: <43372.1430159842@server1.tristatelogic.com> (Ronald F. Guilmette's message of "Mon, 27 Apr 2015 11:37:22 -0700") Message-ID: <44a8xte4i0.fsf@lowell-desk.lan> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.5 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain 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: Mon, 27 Apr 2015 19:49:25 -0000 "Ronald F. Guilmette" writes: > I am prompted to ask here whether or not FreeBSD performs any sort of > logging of instances when "duplicate TCP packets but with different > payloads" occurs, and/or whether FreeBSD provides any options which, > for example, might automagically trigger a close of the relevant TCP > connection when and if such an event is detected. (Connection close > seems to me to be one possible mitigation strategy, even if it might > be viewed as rather ham-fisted by some.) As far as I can see, no. This would be a non-trivial application of resources, so I wouldn't expect to see it be a standard part of the TCP stack. Such a check would be better implemented as an optional application of an API like BPF. From owner-freebsd-security@FreeBSD.ORG Mon Apr 27 19:57:19 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 0E5E1B8C for ; Mon, 27 Apr 2015 19:57:19 +0000 (UTC) Received: from mail-in7.apple.com (mail-out7.apple.com [17.151.62.29]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id DE383149E for ; Mon, 27 Apr 2015 19:57:18 +0000 (UTC) Received: from relay3.apple.com (relay3.apple.com [17.128.113.83]) by mail-in7.apple.com (Apple Secure Mail Relay) with SMTP id 5B.70.09370.D949E355; Mon, 27 Apr 2015 12:57:17 -0700 (PDT) X-AuditID: 11973e16-f79856d00000249a-2b-553e949ddda1 Received: from [17.149.227.61] (Unknown_Domain [17.149.227.61]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by relay3.apple.com (Apple SCV relay) with SMTP id 46.65.22377.7A49E355; Mon, 27 Apr 2015 12:57:27 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\)) Subject: Re: Logging TCP anomalies From: Charles Swiger In-Reply-To: <43372.1430159842@server1.tristatelogic.com> Date: Mon, 27 Apr 2015 12:57:16 -0700 Cc: freebsd-security@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <43372.1430159842@server1.tristatelogic.com> To: "Ronald F. Guilmette" X-Mailer: Apple Mail (2.2098) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrDLMWRmVeSWpSXmKPExsUi2FAYrDt3il2owZ9f/BY9m56wWby6/IrN gcljxqf5LB73NzUyBzBFcdmkpOZklqUW6dslcGVcnD2HueAsV8W08//YGxhPc3QxcnBICJhI TH3H3cXICWSKSVy4t56ti5GLQ0hgL6NEf+8DdoiEicTHjx3sEImpTBKb5v1kBkkwC2hJ3Pj3 kgnE5hXQk3j09DFYg7CAksTLDYcZQRawCahJTJjIAxLmFLCUaJ++hxXEZhFQlVgyeRMLxBgF icnzv0ON1JZYtvA1M8RIK4lX55aC1QgJWEgsuXORHWSkiIChxPppzhDny0p83SoHcpmEwFdW iSN93xgnMArNQnLcLCTHzUKyYQEj8ypGodzEzBzdzDxzvcSCgpxUveT83E2MoOCdbie2g/Hh KqtDjAIcjEo8vAWTbUOFWBPLiitzDzFKc7AoifMuCbQLFRJITyxJzU5NLUgtii8qzUktPsTI xMEp1cBoZJkszDl5GUOBoqrtruP7jT8Z1Vycv+J/1/sXJh+4M6+eWl1lefyGsGmeD5uV1v3c D394XG25S80u1jm9OCuRFT/Nm3F+/d4VkiEWXBtdfudpC3TJ/pf8USsp7CbzeMOF0me1YqFr FxpdSBCbtdLVPnUG3zL1toBVe9S/NQY/+93xpX5Wn78SS3FGoqEWc1FxIgD0WtncPwIAAA== X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrALMWRmVeSWpSXmKPExsUiOPWxre7yKXahBme2M1n0bHrCZvHq8is2 ByaPGZ/ms3jc39TIHMAUxWWTkpqTWZZapG+XwJVxcfYc5oKzXBXTzv9jb2A8zdHFyMkhIWAi 8fFjBzuELSZx4d56ti5GLg4hgalMEpvm/WQGSTALaEnc+PeSCcTmFdCTePT0MViDsICSxMsN hxm7GDk42ATUJCZM5AEJcwpYSrRP38MKYrMIqEosmbyJBWKMgsTk+d+hRmpLLFv4mhlipJXE q3NLwWqEBCwklty5yA4yUkTAUGL9NGcQU0JAVuLrVrkJjPyzkNwzC8k9s5AMXcDIvIpRoCg1 J7HSWC+xoCAnVS85P3cTIyjcGgqDdzD+WWZ1iFGAg1GJh7dgsm2oEGtiWXFl7iFGCQ5mJRHe yZl2oUK8KYmVValF+fFFpTmpxYcYpTlYlMR5OyssQoUE0hNLUrNTUwtSi2CyTBycUg2MaywE jssvfPvoWMOO5gnBXI5Rzk/OTODymFIZrCIio2x77Iroin3mrrs+t7wxdTVzUPm6p7L1tPTv 6tW2b/texX3+X2a9W2VXjLOV9Rz3xPRMuWNfecPi3zALPJhwcX5Q7dqUqKVH3qvZ3V/KzDDl Wfp/Xb61mkEbFqnbzQpRsFXRz9m93bhHiaU4I9FQi7moOBEACf8sRzMCAAA= 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: Mon, 27 Apr 2015 19:57:19 -0000 On Apr 27, 2015, at 11:37 AM, Ronald F. Guilmette = wrote: > I am prompted to ask here whether or not FreeBSD performs any sort of > logging of instances when "duplicate TCP packets but with different > payloads" occurs, Not normally. Such things can be visible in netstat -s output as = "completely duplicate packets", "packets with some dup. data", etc and maybe = enabling network debugging sysctls would give more visibility. They'd also = generate vast amounts of logging for normal network activity. > and/or whether FreeBSD provides any options which, > for example, might automagically trigger a close of the relevant TCP > connection when and if such an event is detected. (Connection close > seems to me to be one possible mitigation strategy, even if it might > be viewed as rather ham-fisted by some.) You need to be able to distinguish normal dup packets or dropping = connections will break normal traffic. For that matter, an attacker could try to = spoof legit connections and your countermeasure would presumably zap the legit connection. Use a firewall which tracks connection state, drops out-of-window = packets, forces fragmented packet reassembly to be performed, uses protocol-aware proxies to validate the content of traffic where possible. Regards, --=20 -Chuck From owner-freebsd-security@FreeBSD.ORG Mon Apr 27 22:02:19 2015 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 8C26B9B5 for ; Mon, 27 Apr 2015 22:02:19 +0000 (UTC) Received: from outgoing.tristatelogic.com (segfault.tristatelogic.com [69.62.255.118]) by mx1.freebsd.org (Postfix) with ESMTP id 71F2B148A for ; Mon, 27 Apr 2015 22:02:18 +0000 (UTC) Received: from segfault-nmh-helo.tristatelogic.com (localhost [127.0.0.1]) by segfault.tristatelogic.com (Postfix) with ESMTP id 5BAD73ADE4 for ; Mon, 27 Apr 2015 15:02:18 -0700 (PDT) From: "Ronald F. Guilmette" To: freebsd-security@freebsd.org Subject: Re: Logging TCP anomalies In-Reply-To: <44a8xte4i0.fsf@lowell-desk.lan> Date: Mon, 27 Apr 2015 15:02:18 -0700 Message-ID: <44745.1430172138@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: Mon, 27 Apr 2015 22:02:19 -0000 In message <44a8xte4i0.fsf@lowell-desk.lan>, Lowell Gilbert wrote: >"Ronald F. Guilmette" writes: > >> I am prompted to ask here whether or not FreeBSD performs any sort of >> logging of instances when "duplicate TCP packets but with different >> payloads" occurs, and/or whether FreeBSD provides any options which, >> for example, might automagically trigger a close of the relevant TCP >> connection when and if such an event is detected. (Connection close >> seems to me to be one possible mitigation strategy, even if it might >> be viewed as rather ham-fisted by some.) > >As far as I can see, no. This would be a non-trivial application of >resources... It would surely be enlightening for me if you could elaborate on that statement a bit. As I understand it, the problem is that two TCP packets, both having the same sequence number, but with different lengths/content arrive at one endpoint or the other of an established TCP connection within some relatively brief period of time. (One of them is legit and the other, fradulent.) Hypothetically, if for example, the FreeBSD TCP stack were to maintain, for each TCP connection, a record of the sequence number of _just_ the most recently received and accepted packet (32 bits), and also the length of that same most-recently-received-and-accepted packet... let's just say for convenience another 32 bits... then if the next subsequent packet which arrives to that same socket endpoint contains (a) the exact same sequence number as the immediately prior one, but also (b) a different length, then could that packet not be then judged to be indicative of a clear attempt at chicanery? Please note that what I just described above requires only two additional 32 bit words per TCP connection and only two additional 32-bit integer comparisons operations per packet. Neither the amount of increased memory nor the amount of incresed computation seem to me as being particularly egregious, given the potential benefit of possibly catching out this kind of funny business, when and if it occurs. Regards, rfg From owner-freebsd-security@FreeBSD.ORG Mon Apr 27 22:12:44 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 3600DC25 for ; Mon, 27 Apr 2015 22:12:44 +0000 (UTC) Received: from outgoing.tristatelogic.com (segfault.tristatelogic.com [69.62.255.118]) by mx1.freebsd.org (Postfix) with ESMTP id 1CB731606 for ; Mon, 27 Apr 2015 22:12:43 +0000 (UTC) Received: from segfault-nmh-helo.tristatelogic.com (localhost [127.0.0.1]) by segfault.tristatelogic.com (Postfix) with ESMTP id 69AB63AEF8 for ; Mon, 27 Apr 2015 15:12:43 -0700 (PDT) From: "Ronald F. Guilmette" To: freebsd-security@freebsd.org Subject: Re: Logging TCP anomalies In-Reply-To: Date: Mon, 27 Apr 2015 15:12:43 -0700 Message-ID: <44814.1430172763@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: Mon, 27 Apr 2015 22:12:44 -0000 In message , Charles Swiger wrote: >On Apr 27, 2015, at 11:37 AM, Ronald F. Guilmette wrot >e: ... >> and/or whether FreeBSD provides any options which, >> for example, might automagically trigger a close of the relevant TCP >> connection when and if such an event is detected. (Connection close >> seems to me to be one possible mitigation strategy, even if it might >> be viewed as rather ham-fisted by some.) > >You need to be able to distinguish normal dup packets Yes. 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. 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. 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). >For that matter, an attacker could try to spoof >legit connections and your countermeasure would presumably zap the legit >connection. Doesn't that reduce down to essentially the problem of guessing TCP sequence numbers? My understanding is that that is a fundamentally hard problem. (I hope so anyway.) And thus, the probability of what you just suggested approaches zero. If I'm wrong, then I would be more than happy to be corrected/enlightened. Regards, rfg From owner-freebsd-security@FreeBSD.ORG Mon Apr 27 22:37:21 2015 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 6D011EEB for ; Mon, 27 Apr 2015 22:37:21 +0000 (UTC) Received: from mail-in5.apple.com (mail-out5.apple.com [17.151.62.27]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 48CDE183F for ; Mon, 27 Apr 2015 22:37:20 +0000 (UTC) Received: from relay4.apple.com (relay4.apple.com [17.128.113.87]) by mail-in5.apple.com (Apple Secure Mail Relay) with SMTP id 61.3E.12430.A1ABE355; Mon, 27 Apr 2015 15:37:14 -0700 (PDT) X-AuditID: 11973e13-f79d56d00000308e-d2-553eba1a1a04 Received: from [17.149.227.61] (Unknown_Domain [17.149.227.61]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by relay4.apple.com (Apple SCV relay) with SMTP id 2C.9C.09819.58ABE355; Mon, 27 Apr 2015 15:39:01 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\)) Subject: Re: Logging TCP anomalies From: Charles Swiger In-Reply-To: <44814.1430172763@server1.tristatelogic.com> Date: Mon, 27 Apr 2015 15:37:13 -0700 Cc: freebsd-security@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <44814.1430172763@server1.tristatelogic.com> To: "Ronald F. Guilmette" X-Mailer: Apple Mail (2.2098) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrDLMWRmVeSWpSXmKPExsUi2FAYriu1yy7U4MA/AYueTU/YLF5dfsXm wOQx49N8Fo/7mxqZA5iiuGxSUnMyy1KL9O0SuDLmLp3FVPBMtOL1sTtsDYzrBLsYOTkkBEwk ju15wwZhi0lcuLceyObiEBLYyyjxfPEtRpiiJ03H2CESU5kkLv9fzQqSYBbQkrjx7yUTiM0r oCfx6OljdhBbWEBJ4uWGw0DNHBxsAmoSEybygIQ5BSwlji6aAzaTRUBVYsm2U1BjFCQmz//O DGFrSyxb+JoZYqSVROuzb2AjhQQsJJ49O8gKMlJEwFBi/TRnEFNCQFbi61Y5iCu/skqc/SE3 gVFoFpLbZiG5bRaSBQsYmVcxCuUmZuboZuaZ6iUWFOSk6iXn525iBAXvdDvhHYynV1kdYhTg YFTi4V241zZUiDWxrLgy9xCjNAeLkjjvkkC7UCGB9MSS1OzU1ILUovii0pzU4kOMTBycUg2M tZ2e5mvu2ZxyeszgfDN/pc1tyeCtbNXsrl8ZX07YsqpFurXlyD3RSZ9Sp0+R6z/PonnlFdvy G127ZfhORDq1+XyTs31xlf3xivWCwiWROer/D5xImCX97E7eF+EXvqFM09RXHLm9iMOtn2VJ Tol6qZLf8jmLHA69vDX/2SmR4IWrVJ7+PxDMosRSnJFoqMVcVJwIAATNlv0/AgAA X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrALMWRmVeSWpSXmKPExsUiOPWxrW7rLrtQg/VvjSx6Nj1hs3h1+RWb A5PHjE/zWTzub2pkDmCK4rJJSc3JLEst0rdL4MqYu3QWU8Ez0YrXx+6wNTCuE+xi5OSQEDCR eNJ0jB3CFpO4cG89WxcjF4eQwFQmicv/V7OCJJgFtCRu/HvJBGLzCuhJPHr6GKxBWEBJ4uWG w4xdjBwcbAJqEhMm8oCEOQUsJY4umsMIYrMIqEos2XYKaoyCxOT535khbG2JZQtfM0OMtJJo ffYNbKSQgIXEs2cHWUFGiggYSqyf5gxiSgjISnzdKjeBkX8WkntmIblnFpKhCxiZVzEKFKXm JFaa6CUWFOSk6iXn525iBIVbQ2H4DsZ/y6wOMQpwMCrx8BZMtg0VYk0sK67MPcQowcGsJMJ7 aotdqBBvSmJlVWpRfnxRaU5q8SFGaQ4WJXHeZxUWoUIC6YklqdmpqQWpRTBZJg5OqQZGmes8 x91mbdNik1rNGsFtZhisE+J7/ufZrcc098279KbCeMZdl09x7g3rJ6by8z7cajDr89ylZ8NP TNaPjo8XbezN+f60+rjosZdeE69f99KpO8nJNttkvjZnaeP0ZHWxhaI8Loqm0ZXzZMPFVj4r zPzwssfW4MVvtbSGtTZzzRMnnuEsWpevxFKckWioxVxUnAgASWGHXDMCAAA= 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: Mon, 27 Apr 2015 22:37:21 -0000 On Apr 27, 2015, at 3:12 PM, Ronald F. Guilmette = wrote: > In message ,=20 > Charles Swiger wrote: >> On Apr 27, 2015, at 11:37 AM, Ronald F. Guilmette = wrote: >>> ... >>> and/or whether FreeBSD provides any options which, >>> for example, might automagically trigger a close of the relevant TCP >>> connection when and if such an event is detected. (Connection close >>> seems to me to be one possible mitigation strategy, even if it might >>> be viewed as rather ham-fisted by some.) >>=20 >> You need to be able to distinguish normal dup packets >=20 > Yes. >=20 > 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. (Simply firing up your companies' VPN can be enough to cause such a = situation.) > 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-- TSO hardware will tend to drop the packet with = very little visibility. > 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. >> For that matter, an attacker could try to spoof >> legit connections and your countermeasure would presumably zap the = legit >> connection. >=20 > Doesn't that reduce down to essentially the problem of guessing TCP=20 > sequence numbers? You have to guess or be able to observe the TCP connection tuple, IPID, = TCP sequence #. > My understanding is that that is a fundamentally hard problem. (I = hope > so anyway.) And thus, the probability of what you just suggested > approaches zero. It's trivial if you can observe the traffic flowing past in transit. It's also fairly easy to guess if you know most or all of the connection = tuple info and the host is using a typical global linear IPID generation method, = because you only have to guess a sequence # within the open window. Regards, --=20 -Chuck From owner-freebsd-security@FreeBSD.ORG Mon Apr 27 23:09:58 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 98CCC499 for ; Mon, 27 Apr 2015 23:09:58 +0000 (UTC) Received: from mail-vn0-f41.google.com (mail-vn0-f41.google.com [209.85.216.41]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 5A8E21C25 for ; Mon, 27 Apr 2015 23:09:54 +0000 (UTC) Received: by vnbg62 with SMTP id g62so14098690vnb.7 for ; Mon, 27 Apr 2015 16:09:53 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :subject:content-type:content-transfer-encoding; bh=47DEQpj8HBSa+/TImW+5JCeuQeRkm5NMpJWZG3hSuFU=; b=US4vDjy171WKFuNMz58LY34My91UVNpI8LMwW7muHxg/+qiff9hPGzvesy/De3UXqh Td9DxZaI7dqUzzJYC8A8XdiQrmsM22vxnRc33PG9SB8YSr4+WQTc6SnPm0TnOTLH5lTP Gmq5KmqAUqp/bsl7+hdgnNWe4goJvXsezaqHOTpwyzq/+hSAS8wKjanGewixJCBosNdt ZceVgoQAlwI3FGoXo6hbcX0WwfjhQReNQpxbyjePZ/zZsKyDCIBZwUEPjrZIDmp3iFcm KWWBl1Nz1bodcbCqwtM76T47moW60d3evRIcSDFxym2GAlav5Q4wMOSX6qFU+gzC5s8T PD/w== X-Gm-Message-State: ALoCoQnokw6Uy6o9l/esK6imkUJJyGoPr/c+9RUiTjsvsm/cQSK0JokPz4bsAquevMAK3OnsGG7f X-Received: by 10.52.65.38 with SMTP id u6mr17085436vds.24.1430175828445; Mon, 27 Apr 2015 16:03:48 -0700 (PDT) Received: from [10.106.5.131] (pool-74-98-43-86.pitbpa.east.verizon.net. [74.98.43.86]) by mx.google.com with ESMTPSA id hb1sm28827953vdb.1.2015.04.27.16.03.47 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 27 Apr 2015 16:03:47 -0700 (PDT) Message-ID: <553EC053.2010905@jimkeener.com> Date: Mon, 27 Apr 2015 19:03:47 -0400 From: James Keener User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: FreeBSD-security@FreeBSD.org Subject: join Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit 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: Mon, 27 Apr 2015 23:09:58 -0000 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 From owner-freebsd-security@FreeBSD.ORG Tue Apr 28 07:30:15 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 120DC709 for ; Tue, 28 Apr 2015 07:30:15 +0000 (UTC) Received: from zxy.spb.ru (zxy.spb.ru [195.70.199.98]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id BC35B1162 for ; Tue, 28 Apr 2015 07:30:14 +0000 (UTC) Received: from slw by zxy.spb.ru with local (Exim 4.84 (FreeBSD)) (envelope-from ) id 1Ymzy0-000P00-84; Tue, 28 Apr 2015 10:30:04 +0300 Date: Tue, 28 Apr 2015 10:30:04 +0300 From: Slawa Olhovchenkov To: "Ronald F. Guilmette" Cc: freebsd-security@freebsd.org Subject: Re: Logging TCP anomalies Message-ID: <20150428073004.GX1394@zxy.spb.ru> References: <44814.1430172763@server1.tristatelogic.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <44814.1430172763@server1.tristatelogic.com> User-Agent: Mutt/1.5.23 (2014-03-12) X-SA-Exim-Connect-IP: X-SA-Exim-Mail-From: slw@zxy.spb.ru X-SA-Exim-Scanned: No (on zxy.spb.ru); SAEximRunCond expanded to false 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 07:30:15 -0000 On Mon, Apr 27, 2015 at 03:12:43PM -0700, Ronald F. Guilmette wrote: > > In message , > Charles Swiger wrote: > > >On Apr 27, 2015, at 11:37 AM, Ronald F. Guilmette wrot > >e: > ... > >> and/or whether FreeBSD provides any options which, > >> for example, might automagically trigger a close of the relevant TCP > >> connection when and if such an event is detected. (Connection close > >> seems to me to be one possible mitigation strategy, even if it might > >> be viewed as rather ham-fisted by some.) > > > >You need to be able to distinguish normal dup packets > > Yes. > > 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. 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. different lengths is legitime -- in case of sender resend-packets and reduce packet sizes (for example from differen interface with different MTU). From owner-freebsd-security@FreeBSD.ORG Tue Apr 28 06:37:26 2015 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 6B85AE72 for ; Tue, 28 Apr 2015 06:37:26 +0000 (UTC) Received: from nitrogen.nk99.org (nitrogen6.nk99.org [IPv6:2a01:4f8:140:21c6::2]) by mx1.freebsd.org (Postfix) with ESMTP id 31F611C15 for ; Tue, 28 Apr 2015 06:37:25 +0000 (UTC) Received: from localhost (localhost [IPv6:::1]) by nitrogen.nk99.org (Postfix) with ESMTP id 8D1542732E for ; Tue, 28 Apr 2015 06:37:23 +0000 (UTC) Received: from ::1 (proxying for 141.228.106.147) (SquirrelMail authenticated user nk@nk99.org) by localhost with HTTP; Tue, 28 Apr 2015 09:37:23 +0300 Message-ID: In-Reply-To: <44814.1430172763@server1.tristatelogic.com> References: <44814.1430172763@server1.tristatelogic.com> Date: Tue, 28 Apr 2015 09:37:23 +0300 Subject: Re: Logging TCP anomalies From: "Nerijus Krukauskas" To: freebsd-security@freebsd.org User-Agent: SquirrelMail/1.4.22 MIME-Version: 1.0 Content-Type: text/plain;charset=utf-8 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal X-Mailman-Approved-At: Tue, 28 Apr 2015 12:01:29 +0000 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 06:37:26 -0000 On Tue, April 28, 2015 01:12, Ronald F. Guilmette wrote: > > In message , > Charles Swiger wrote: > >>On Apr 27, 2015, at 11:37 AM, Ronald F. Guilmette wrot >>e: > ... >>> and/or whether FreeBSD provides any options which, >>> for example, might automagically trigger a close of the relevant TCP >>> connection when and if such an event is detected. (Connection close >>> seems to me to be one possible mitigation strategy, even if it might >>> be viewed as rather ham-fisted by some.) >> >>You need to be able to distinguish normal dup packets > > Yes. > > 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. 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. > > 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). Have you asked yourself a question on how long do you wait for that possible duplicate packet? TCP by design will accept first legitimate packet in sequence. When the duplicate arrives the connection state has already changed. Logging such an event is the most you can get, IMO. -- nk From owner-freebsd-security@FreeBSD.ORG Tue Apr 28 13:20:47 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 A6D334E7 for ; Tue, 28 Apr 2015 13:20:47 +0000 (UTC) Received: from mail-qk0-x236.google.com (mail-qk0-x236.google.com [IPv6:2607:f8b0:400d:c09::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 636B01CE5 for ; Tue, 28 Apr 2015 13:20:47 +0000 (UTC) Received: by qku63 with SMTP id 63so79417583qku.3 for ; Tue, 28 Apr 2015 06:20:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=AIkldWQu0StcD1EXQ5HuHLZxQf7aVa57ETngdhGXOFs=; b=KHa8d8iDqzJOgbjzQvrwGZz1rUFAbDVBrJw96Wo1IILuOCVEEuaqV5gyLpmGKWE7Ym Vaos/EqFxJ3t/j3hpt6j/dBaY7Nfr02tuu/GdYxnpTrlPm3A+ThsmkXJb3v92bUrwrjK w1mwY+gw/3LagTaplD/NiqXPiTZQ38Vfwo8b2eaZ6n/T1abp7Q04JYz/TJ3Oylk2rWDy /+BOODKmPPcIJhgm0VnkMkMb1LSxBkD7n98Q/uz9nKZ/su60uWSteixgqVBVwX21mD+H CoQXVb9/ZU7x4jy7kHTcwpzLzlyhhGUnkEn/LQ3dYavDR/Hlb+HX72FqKMgGmhHyTcUY pMkA== MIME-Version: 1.0 X-Received: by 10.140.36.137 with SMTP id p9mr11622550qgp.16.1430227246574; Tue, 28 Apr 2015 06:20:46 -0700 (PDT) Received: by 10.96.164.168 with HTTP; Tue, 28 Apr 2015 06:20:46 -0700 (PDT) In-Reply-To: <43372.1430159842@server1.tristatelogic.com> References: <43372.1430159842@server1.tristatelogic.com> Date: Tue, 28 Apr 2015 06:20:46 -0700 Message-ID: Subject: Re: Logging TCP anomalies From: Kurt Buff To: freebsd-security@freebsd.org Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.20 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 13:20:47 -0000 Snort (and brethren) at the perimeter seem like a reasonable approach. http://seclists.org/snort/2015/q2/114 But, more likely to succeed will be SSL everywhere, and certificate pinning, since this is primarily a web-based attack: http://www.wired.com/2015/04/researchers-uncover-method-detect-nsa-quantum-insert-hacks/ Kurt On Mon, Apr 27, 2015 at 11:37 AM, Ronald F. Guilmette wrote: > > I just now read the following TheRegister news article about detection > of "Quantum Insert" funny business: > > > http://www.theregister.co.uk/2015/04/23/detecting_nsa_style_hacking_tool_unsheathed/ > > I am prompted to ask here whether or not FreeBSD performs any sort of > logging of instances when "duplicate TCP packets but with different > payloads" occurs, and/or whether FreeBSD provides any options which, > for example, might automagically trigger a close of the relevant TCP > connection when and if such an event is detected. (Connection close > seems to me to be one possible mitigation strategy, even if it might > be viewed as rather ham-fisted by some.) > _______________________________________________ > freebsd-security@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-security > To unsubscribe, send any mail to "freebsd-security-unsubscribe@freebsd.org > " > From owner-freebsd-security@FreeBSD.ORG Tue Apr 28 14:42:23 2015 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id F09F0ED4 for ; Tue, 28 Apr 2015 14:42:22 +0000 (UTC) Received: from be-well.ilk.org (be-well.ilk.org [23.30.133.173]) by mx1.freebsd.org (Postfix) with ESMTP id A91BD1705 for ; Tue, 28 Apr 2015 14:42:22 +0000 (UTC) Received: from lowell-desk.lan (lowell-desk.lan [172.30.250.41]) by be-well.ilk.org (Postfix) with ESMTP id 1728233C1E; Tue, 28 Apr 2015 10:42:16 -0400 (EDT) Received: by lowell-desk.lan (Postfix, from userid 1147) id EC67F39843; Tue, 28 Apr 2015 10:42:14 -0400 (EDT) From: Lowell Gilbert To: "Ronald F. Guilmette" Cc: freebsd-security@freebsd.org Subject: Re: Logging TCP anomalies References: <44745.1430172138@server1.tristatelogic.com> Date: Tue, 28 Apr 2015 10:42:14 -0400 In-Reply-To: <44745.1430172138@server1.tristatelogic.com> (Ronald F. Guilmette's message of "Mon, 27 Apr 2015 15:02:18 -0700") Message-ID: <44iocge2m1.fsf@lowell-desk.lan> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.5 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain 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 14:42:23 -0000 "Ronald F. Guilmette" writes: > In message <44a8xte4i0.fsf@lowell-desk.lan>, > Lowell Gilbert wrote: > >>"Ronald F. Guilmette" writes: >> >>> I am prompted to ask here whether or not FreeBSD performs any sort of >>> logging of instances when "duplicate TCP packets but with different >>> payloads" occurs, and/or whether FreeBSD provides any options which, >>> for example, might automagically trigger a close of the relevant TCP >>> connection when and if such an event is detected. (Connection close >>> seems to me to be one possible mitigation strategy, even if it might >>> be viewed as rather ham-fisted by some.) >> >>As far as I can see, no. This would be a non-trivial application of >>resources... > > It would surely be enlightening for me if you could elaborate on that > statement a bit. > > As I understand it, the problem is that two TCP packets, both having the > same sequence number, but with different lengths/content arrive at one > endpoint or the other of an established TCP connection within some > relatively brief period of time. (One of them is legit and the other, > fradulent.) > > Hypothetically, if for example, the FreeBSD TCP stack were to maintain, > for each TCP connection, a record of the sequence number of _just_ the > most recently received and accepted packet (32 bits), and also the length > of that same most-recently-received-and-accepted packet... let's just > say for convenience another 32 bits... then if the next subsequent > packet which arrives to that same socket endpoint contains (a) the > exact same sequence number as the immediately prior one, but also (b) > a different length, then could that packet not be then judged to be > indicative of a clear attempt at chicanery? Unfortunately not. Duplicated packets will (in most cases, but not all) have the same length as each other, but the sliding window can easily mean that a retransmission will include more data than the original. And on the other side, I'm concerned that you're actually making an *easier* attack possible by possibly dumping a connection based on what could be a lucky guess. Detecting these anomalies is something that most (all, I think, but I'm not motivated enough to check) stateful firewalls will be able to detect. And it's a good idea; even if the extra packets are happening for benign reasons, having a lot of them represents a bug somewhere in your network path, consuming extra network resources. > Please note that what I just described above requires only two additional > 32 bit words per TCP connection and only two additional 32-bit integer > comparisons operations per packet. Neither the amount of increased > memory nor the amount of incresed computation seem to me as being > particularly egregious, given the potential benefit of possibly catching > out this kind of funny business, when and if it occurs. In a forwarding path, you'd still see a measurable performance hit. And it's depending on a very specific set of symptoms that as far as I've been able to imagine, can only be produced by a attacker who would also be able to use the same resources for a variety of other attacks. And the attacker is already able to read some of your traffic *without* interfering with it. Strong encryption, applied at multiple levels, is the only reasonable engineering approach to issues like this. From owner-freebsd-security@FreeBSD.ORG Tue Apr 28 19:48:09 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 AD2F733E for ; Tue, 28 Apr 2015 19:48:09 +0000 (UTC) Received: from new1-smtp.messagingengine.com (new1-smtp.messagingengine.com [66.111.4.221]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 831D91DF6 for ; Tue, 28 Apr 2015 19:48:09 +0000 (UTC) Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailnew.nyi.internal (Postfix) with ESMTP id ED824593 for ; Tue, 28 Apr 2015 15:48:00 -0400 (EDT) Received: from web3 ([10.202.2.213]) by compute3.internal (MEProxy); Tue, 28 Apr 2015 15:48:00 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-sasl-enc:x-sasl-enc; s=smtpout; bh=uov4/EYxRxGPRqt pJLy8iD0cmU0=; b=hnglE9k4ItSlLSsXO5hC3mWECSXqpbrPsq/BPit4O0piZk4 lAJJX0rFnzr2XpuXZMzg61DKfrq5fWB5xqa9USqrUdTG4uvTgKVPztmG6ggKxo73 dYdakkCNMp7KgkMAPZ6PK6AvQD6/YJYroloJSH/LnoXGc2gubXDJINzZwVvY= Received: by web3.nyi.internal (Postfix, from userid 99) id A70A2103D35; Tue, 28 Apr 2015 15:48:00 -0400 (EDT) Message-Id: <1430250480.672566.259824585.439C7F0B@webmail.messagingengine.com> X-Sasl-Enc: fqeLnsV0+lbbMQC6+rnHzbmNiqndwEQ+KNfBE+HNTmUu 1430250480 From: Mark Felder To: freebsd-security@freebsd.org MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain X-Mailer: MessagingEngine.com Webmail Interface - ajax-049af6e1 Subject: Re: base/release/10.1.0/contrib/file vulnerabilities? Date: Tue, 28 Apr 2015 14:48:00 -0500 In-Reply-To: <553DF49E.3020502@riseup.net> References: <553DF49E.3020502@riseup.net> 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 19:48:09 -0000 On Mon, Apr 27, 2015, at 03:34, Piotr Kubaj wrote: > Hi, > > I wrote about this vulnerability in January: > https://lists.freebsd.org/pipermail/freebsd-security/2015-January/008115.html > > There were only patches for stable. > There is an open PR as well https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=198912 From owner-freebsd-security@FreeBSD.ORG Wed Apr 29 22:07:20 2015 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id CCAD2551 for ; Wed, 29 Apr 2015 22:07:20 +0000 (UTC) Received: from smarthost1.sentex.ca (smarthost1.sentex.ca [IPv6:2607:f3e0:0:1::12]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "smarthost.sentex.ca", Issuer "smarthost.sentex.ca" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 98ED41DEC for ; Wed, 29 Apr 2015 22:07:20 +0000 (UTC) Received: from [IPv6:2607:f3e0:0:4:f025:8813:7603:7e4a] (saphire3.sentex.ca [IPv6:2607:f3e0:0:4:f025:8813:7603:7e4a]) by smarthost1.sentex.ca (8.14.9/8.14.9) with ESMTP id t3TM7JHJ028314; Wed, 29 Apr 2015 18:07:19 -0400 (EDT) (envelope-from mike@sentex.net) Message-ID: <5541560C.5020004@sentex.net> Date: Wed, 29 Apr 2015 18:07:08 -0400 From: Mike Tancsa Organization: Sentex Communications User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: "freebsd-security@freebsd.org" Subject: SA-14:19 (Denial of Service in TCP packet processing) and jails issue ? Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit 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: Wed, 29 Apr 2015 22:07:20 -0000 While running a Qualys scan against one of our RELENG_9 boxes (9.3-STABLE #16 r281494), it came up complaining about the SA below as an issue still ? https://www.freebsd.org/security/advisories/FreeBSD-SA-14:19.tcp.asc The server should have this fix in place no ? # svn info /usr/src Path: /usr/src Working Copy Root Path: /usr/src URL: svn://svn.freebsd.org/base/stable/9 Relative URL: ^/stable/9 Repository Root: svn://svn.freebsd.org/base Repository UUID: ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f Revision: 281494 Node Kind: directory Schedule: normal Last Changed Author: jkim Last Changed Rev: 281389 Last Changed Date: 2015-04-10 21:17:19 -0400 (Fri, 10 Apr 2015) Also, we have pf in place with the first rule being #block everything by default coming in block in log all and then explicitly letting in the ports we want, with keep state The IP being scanned is in a jail. If I run the scan to an IP not associated with the jail, the scan does not complain. Its only on the jailed IP that the scan flags as problematic for this vulnerability. Looking at the src of tcp_input.c, I see todrop = tp->rcv_nxt - th->th_seq; if (todrop > 0) { if (thflags & TH_SYN) { thflags &= ~TH_SYN; th->th_seq++; if (th->th_urp > 1) th->th_urp--; else thflags &= ~TH_URG; todrop--; } so the code path looks right based on the commit in https://lists.freebsd.org/pipermail/svn-src-stable-9/2014-September/007198.html If this is a false positive, how can I be sure thats the case ? I have pcaps of the scan both against the jailed IP (with the scan saying its vulnerable) and against an IP not associated with the jail, saying its not an issue. QID: 82054 Category: TCP/IP CVE ID: CVE-2004-0230 Vendor Reference - Bugtraq ID: 10183 Service Modified: 02/02/2010 User Modified: - Edited: No PCI Vuln: No Ticket State: TCP provides stateful communications between hosts on a network. TCP sessions are established by a three-way handshake and use random 32-bit sequence and acknowledgement numbers to ensure the validity of traffic. A vulnerability was reported that may permit TCP sequence numbers to be more easily approximated by remote attackers. This issue affects products released by multiple vendors. The cause of the vulnerability is that affected implementations will accept TCP sequence numbers within a certain range, known as the acknowledgement range, of the expected sequence number for a packet in the session. This is determined by the TCP window size, which is negotiated during the three-way handshake for the session. Larger TCP window sizes may be set to allow for more throughput, but the larger the TCP window size, the more probable it is to guess a TCP sequence number that falls within an acceptable range. It was initially thought that guessing an acceptable sequence number was relatively difficult for most implementations given random distribution, making this type of attack impractical. However, some implementations may make it easier to successfully approximate an acceptable TCP sequence number, making these attacks possible with a number of protocols and implementations. This is further compounded by the fact that some implementations may support the use of the TCP Window Scale Option, as described in RFC 1323, to extend the TCP window size to a maximum value of 1 billion. This vulnerability will permit a remote attacker to inject a SYN or RST packet into the session, causing it to be reset and effectively allowing for denial of service attacks. An attacker would exploit this issue by sending a packet to a receiving implementation with an approximated sequence number and a forged source IP address and TCP port. There are a few factors that may present viable target implementations, such as those which depend on long-lived TCP connections, those that have known or easily guessed IP address endpoints and those implementations with easily guessed TCP source ports. It has been noted that Border Gateway Protocol (BGP) is reported to be particularly vulnerable to this type of attack, due to the use of long-lived TCP sessions and the possibility that some implementations may use the TCP Window Scale Option. As a result, this issue is likely to affect a number of routing platforms. Another factor to consider is the relative difficulty of injecting packets into TCP sessions, as a number of receiving implementations will reassemble packets in order, dropping any duplicates. This may make some implementations more resistant to attacks than others. It should be noted that while a number of vendors have confirmed this issue in various products, investigations are ongoing and it is likely that many other vendors and products will turn out to be vulnerable as the issue is investigated further. -- ------------------- Mike Tancsa, tel +1 519 651 3400 Sentex Communications, mike@sentex.net Providing Internet services since 1994 www.sentex.net Cambridge, Ontario Canada http://www.tancsa.com/