Date: Sun, 31 Jul 2016 11:25:31 -0700 (PDT) From: Roger Marquis <marquis@roble.com> To: Martin Schroeder <mschroeder@vfemail.net> Cc: freebsd-security@freebsd.org, security-officer@FreeBSD.org Subject: Re: freebsd-update and portsnap users still at risk of compromise In-Reply-To: <6bd80e384e443e5de73fb951e973b221@vfemail.net> References: <6bd80e384e443e5de73fb951e973b221@vfemail.net>
| previous in thread | raw e-mail | index | archive | help
Question is does this warrant moving from portsnap to svn? Also have to wonder why the security team hasn't issued a vulnerability announcement. Roger > 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: > > ...
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?>