Multiple bugs in libarchive sandboxing code

[Messenger258]

caught this post elsewhere.

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.

[FlorianHeigl]

Accept please?

[jsonn]

It seems the only relevant part is the symlink checking thing?

[kientzle]

There seem to be three libarchive issues described in this document. (Actually four, but the first listed "Vulnerability #1" was already fixed.) The key first step, of course, is formulate and commit appropriate tests for each of these. Then we can work through the best way to solve them.

Here are a few thoughts based on a cursory skim:

"Vulnerability #2"

https://gist.github.com/anonymous/e48209b03f1dd9625a992717e7b89c4f#file-freebsd-txt-L663

This describes a bad interaction between the symlink tests and the deep directory handling. I could be talked into dumping the deep-directory handling as the author suggests, though I would like to at least try to find a better solution.

"Vulnerability #3"

https://gist.github.com/anonymous/e48209b03f1dd9625a992717e7b89c4f#file-freebsd-txt-L746

This describes another problem with symlink checks: I suspect this is a simple fix to ensure that the matching prefix terminates at a path component. I recall someone else mentioning this issue but cannot recall if it was already fixed.

"Vulnerability #4"

https://gist.github.com/anonymous/e48209b03f1dd9625a992717e7b89c4f#file-freebsd-txt-L835

This claims that hard links with data payloads can escape the sandbox. The first question I would need to research is whether this capability in archive_write_disk is used by any non-tar format. In particular, I recall that newc cpio format handles hard links backwards from traditional tar, which may rely on this code. If newc relies on this, then the author's advice to just remove this capability isn't really feasible. (Even apart from newc, I'm a bit reluctant to drop a POSIX-mandated feature of this sort.)

[WayneSK]

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.

[kientzle]

To make it easier to track and discuss, I've broken this into separate issues for each problem mentioned in the report:

The first vulnerability was fixed in commit 6a7b8ad
The second is now Issue #744
The third is now Issue #745
The fourth is now Issue #746

[kientzle]

I just committed test cases to exercise the sandbox code. Any candidate fixes for these issues should be verified against those test cases. (Of course, please let me know if you think the test cases are insufficient.)

[kientzle]

Note: Credit is also due to Lu Tung Pin, who provided a copy of this document to the FreeBSD Security team prior to it being posted here.

I believe the recent work by Doran Moppert fixes all of these reported issues.