>Number:         18840
>Category:       bin
>Synopsis:       Fix for PR/18663 incomplete (pax symlink handling)
>Confidential:   yes
>Severity:       critical
>Priority:       high
>Responsible:    bin-bug-people
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Mon Oct 28 07:26:01 PST 2002
>Closed-Date:
>Last-Modified:
>Originator:     Frederick Bruckman
>Release:        NetBSD 1.6J
>Organization:
>Environment:
	
	
System: NetBSD induction.immanent.net 1.6J NetBSD 1.6J (INDUCTION) #0: Sun Oct 27 01:18:44 CST 2002 fredb@tautology.immanent.net:/s/src-current/sys/arch/mac68k/compile/INDUCTION mac68k
	(Bug affects all architectures.)
>Description:
	
	The fix for PR/18663 pulled up from the "pax" maintainers
	(to deny trojans based on traversal of relative symlinks),
	assumes that "pax" follows the documented strategy for
	absolute symlinks. On NetBSD, it does not. Observe:

	# ln -fs /tmp
	# touch /tmp/foo
	# pax -x tar -w ./tmp ./tmp/foo > tmp.foo.tar
	# rm tmp /tmp/foo
	# pax -r -f tmp.foo.tar 
	# ls -l tmp /tmp/foo
	-rw-r--r--  1 fredb  wheel  0 Oct 28 09:01 /tmp/foo
	lrwxr-xr-x  1 fredb  wheel  4 Oct 28 09:01 tmp -> /tmp

	Note that, even without "--insecure", a file was created in
	a fixed, absolute location without warning. "/tmp/foo" could
	easily have been "/bin/sh". Such an archive distributed on
	the web would leave a big booby-trap for an unwary root user
	(someone, say, building packages).

	I dimly recall that, when it was allowed to let "pax" extract
	absolute symlinks for the benefit of "sysinstall", the
	possibility of such trojans was briefly considered. Ironically,
	the concerns were rejected because of the obvious, gaping hole
	regarding relative symlinks (which is now brutally closed).

>How-To-Repeat:
	
	See above.
>Fix:
	
	Todd Vierling has fielded a proposal, in

	http://mail-index.netbsd.org/tech-security/2002/10/26/0000.html,

	which appears to be adequate to cover the goof regarding absolute
	symlinks, while mitigating some of the problems the absolute
	prohibiton on relative symlinks has caused for the package tools.

	In a follow-on to that, Gregg Woods illustrates a possible
	exploit requiring both a malicious archive *and* a local
	user. While apparently valid, the serious, gaping hole regarding
	absolute symlinks (which I'm declining to discuss publicly, hence
	the confidential status of this PR), is more pressing, and so the
	fix should not be delayed (IMHO).

	Note that simply restoring "pax"s still-documented behavior for
	absolute symlinks in archives would make it impossible to extract
	old NetBSD distributions, in addition to requiring changes to
	NetBSD's build system and strategy. I don't find that acceptable.
>Release-Note:
>Audit-Trail:
>Unformatted:
 	2002-10-27