[Bug 10651] tar: check for unsafe symlinks is overly strict

[bugzilla at busybox.net]

https://bugs.busybox.net/show_bug.cgi?id=10651

--- Comment #4 from Denys Vlasenko <vda.linux at googlemail.com> ---
(In reply to Daniel Goertzen from comment #3)
> At this point it is simpler and more robust for me to switch to gnu tar rather than maintain EXTRACT_UNSAFE_SYMLINKS=1 in all the right places.

Well then, the following will be happening:
> MavProxyUser 2017-07-06 17:30:44 UTC
> I can now confirm that this has been exploited "in the wild" to root / jailbreak DJI Mavic, Spark, Inspire2, and Phantom 4 drone series. 
> Exploit here for posterity
> https://github.com/MAVProxyUser/P0VsRedHerring/blob/master/RedHerring.rb#L24
> Thanks for pushing to get this patched. It has festered for a while.

It is inescapable fact of life that more secure systems are "less convenient",
they would require more steps.

It is a balancing act somewhere between having (in this case) tar which will
untar anything anywhere, and tar which requires some awful crypto-signed
tarballs (this will be very safe, but basically unusable).

I am not a security nutjob. I _am_ trying to find a balance, not just bolt
everything down to the point where it's securely useless.


With EXTRACT_UNSAFE_SYMLINKS=1 thing, I defend even against the case where
attacker provides two tarballs, with 1st creating evil symlink, and another
using it. GNU tar's solution of delayed symlink creation is defeated by that. 
 *and*
unlike a solution of requiring a special option, "tar
--extract-unsafe-symlinks", this one does not wreak havoc for all your scripts
with tar invocations: envvars are _inherited_. You can just set it in your
login environment once, and bingo: all tar invocations will start acting as you
want. 

Propose something better, or how to tweak this solution to be more usable.

Specifically, what we have here are symlinks in /sbin to /bin/busybox.
Hilariously ad-hoc, but working for us busyboxers solution would be to allow
creation of symlinks which end with "bin/busybox" or "/[s]bin/busybox" ;)

-- 
You are receiving this mail because:
You are on the CC list for the bug.