Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Multiple bugs in libarchive sandboxing code #743

Closed
Messenger258 opened this issue Jul 14, 2016 · 7 comments
Closed

Multiple bugs in libarchive sandboxing code #743

Messenger258 opened this issue Jul 14, 2016 · 7 comments
Milestone
3.2.2

Comments

Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
3.2.2
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
5 participants
@jsonn @kientzle @FlorianHeigl @Messenger258 @WayneSK
@Messenger258
Copy link

@Messenger258 Messenger258 commented Jul 14, 2016

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
Copy link

@FlorianHeigl FlorianHeigl commented Jul 18, 2016 •
edited

Accept please?

@jsonn
Copy link
Contributor

@jsonn jsonn commented Jul 18, 2016

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

@kientzle
Copy link
Contributor

@kientzle kientzle commented Jul 19, 2016

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
Copy link

@WayneSK WayneSK commented Jul 19, 2016

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 kientzle mentioned this issue Jul 21, 2016
Closed
@kientzle kientzle mentioned this issue Jul 21, 2016
Closed
@kientzle kientzle mentioned this issue Jul 21, 2016
Closed
@kientzle
Copy link
Contributor

@kientzle kientzle commented Jul 21, 2016

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 kientzle changed the title multiple libarchive vulnerabilities connected to advanced threat actor attacks against freebsd and linux Multiple bugs in libarchive sandboxing code Jul 21, 2016
@kientzle
Copy link
Contributor

@kientzle kientzle commented Aug 10, 2016

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 added a commit that referenced this issue Aug 22, 2016
@kientzle
Issue #744 (part of Issue #743): Enforce sandbox with very long pathn…
1fa9c7b 
…ames

Because check_symlinks is handled separately from the deep-directory
support, very long pathnames cause problems.  Previously, the code
ignored most failures to lstat() a path component.  In particular,
this led to check_symlinks always passing for very long paths, which
in turn provides a way to evade the symlink checks in the sandboxing
code.

We now fail on unrecognized lstat() failures, which plugs this
hole at the cost of disabling deep directory support when the
user requests sandboxing.

TODO:  This probably cannot be completely fixed without
entirely reimplementing the deep directory support to
integrate the symlink checks.  I want to reimplement the
deep directory hanlding someday anyway; openat() and
related system calls now provide a much cleaner way to
handle deep directories than the chdir approach used by this
code.
@kientzle
Copy link
Contributor

@kientzle kientzle commented Sep 18, 2016

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.

@kientzle kientzle closed this Sep 18, 2016
@kientzle kientzle added this to the 3.2.2 milestone Sep 18, 2016
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment