Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
Multiple bugs in libarchive sandboxing code #743
caught this post elsewhere.
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:
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.
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.
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.)
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.