From ${URL} : - pax Report: https://bugs.debian.org/774716 and http://www.openwall.com/lists/oss-security/2015/01/07/5 @maintainer(s): after the bump, in case we need to stabilize the package, please let us know if it is ready for the stabilization or not.
CVE-2015-1194 (http://nvd.nist.gov/nvd.cfm?cvename=CVE-2015-1194): pax 1:20140703 allows remote attackers to write to arbitrary files via a symlink attack in an archive. CVE-2015-1193 (http://nvd.nist.gov/nvd.cfm?cvename=CVE-2015-1193): Multiple directory traversal vulnerabilities in pax 1:20140703 allow remote attackers to write to arbitrary files via a (1) full pathname or (2) .. (dot dot) in an archive.
It has been some time since this Bug received an update. Since it is security related, bringing it up to the surface so it is not forgotten. Any updates?
The matter was addressed by Phillip Guenther in OpenBSD 5.6 Errata 24. http://ftp.openbsd.org/pub/OpenBSD/patches/5.6/common/024_tar.patch.sig However, I think that serious consideration should be given to dropping this package altogether. Here's why: * Poor maintainership; possibly dead: the HOMEPAGE is wrong and the RPM spec contains a dead link to an OpenSUSE maintainer's directory. * The last update shown in the ChangeLog was in 2005 (although OpenSUSE may have a newer source RPM) * This fork appears to be based on an old MirBSD implementation, which is, in turn, a fork from the OpenBSD sources. * This version of pax is junk because it cannot even produce archives in the format defined by POSIX.1-2001, which is the standard that defines both the pax utility and archive format to begin with! Yet, GNU tar has a --format=pax option. * The OpenSUSE maintainer chooses to ignore the ramifications of the previous point: https://bugzilla.novell.com/show_bug.cgi?id=548468 For a version of pax that is actually conformant, we already have sys-apps/heirloom-tools and I would recommend anyone that needs pax(1) to consider using that instead. Those that are not interested in creating archives in pax format are better off using GNU tar, which is superior in terms of maintenance and code quality. It is also the best option for those Linux users who want to create pax archives but do not require the pax(1) interface.
Thomas: have you seen these CVE's ? i've tested the latest version in cvs: https://www.mirbsd.org/cvs.cgi/src/bin/pax/ it fails the test case that Debian provides: https://bugs.debian.org/774716 test case: echo hello > ../file paxtar cvf test.tar ../file rm ../file paxtar xvf test.tar that'll create ../file when it shouldn't have. the openbsd version filters it: tar: Removing leading "../" file could you resync the pax code w/the latest openbsd ?
Resync of paxmirabilis with OpenBSD code in progress. I’m mostly done with it, but it needs major testing and has impact on porting to GNU OS (like Gentoo/Linux), so it won’t be ready tonight like I planned ☹
(In reply to Thorsten Glaser from comment #5) have you seen the libbsd package ? i think requiring/utilizing that should be fine considering pax's lineage. http://libbsd.freedesktop.org/wiki/ its API is not as complete as one would hope though :/. i've made some requests upstream to expand it specifically based on some funcs openbsd's pax used.
I know libbsd, I’ve been involved with it from the Debian side. The portability issues I’ve mentioned have nothing to do with missing functions though (albeit there’s reallocarray as new one, that’s not the issue) but more with feature uses, sizes of common data types (your glibc does not offer 64-bit off_t on 32-bit platforms when fts functions are used, for example). Anyway, I have a headache, but I hope to be able to publish a new release of paxmirabilis this weekend.
(In reply to mirabilos from comment #7) 64bit fts support is being worked on in glibc, but it'll be a while before you can require it :/
Yeah well, maybe in glibc 3.0… but I’ll leave that to the packagers. In the meantime I decided to do two paxmirabilis releases: first one containing the relevant backports OpenBSD did only, then, later once the changes are all fully merged (still not there due to intrusive changes both local and upstream to the logging code) and, more importantly, tested (does anyone know of a testsuite for cpio, pax, and tar?) another release with the new codebase. And, mid-term, one that uses mksh’s buildsystem instead of manual cc(1) invocations, and checks for features autoconf-like (making even more things available on OSes that have them). Again, thanks for prodding me. Now, to un-FUD a bit… * not possibly dead, but stable code doesn’t require a release every other week; could use some more attention admittedly * ChangeLog files are not produced by BSD developers, so I’ve got no idea what file you’re talking about * the MirBSD implementation has had active bugfixes (even for some format issues) and new features (several flags for archive normalisation/anonymisation; new archive formats) and will continue to do so * the lack of support for the (rather recent!) “pax” format is a known bug and will eventually be addressed in MirBSD; for now, the standardised ustar format is enough for those who care about the standards (and most real-world usage), and the sv4crc/sv4cpio and cpio formats are enough to have full Unix system interchange, plus the ar format if needed (all in one tool, still less bloated though; for very long, GNU cpio’s ustar format has been broken, for example, which cannot happen here) * the heirloom tools, while an admirable project, do pretty much the same as MirBSD (work on inherited codebases), except they use even older stuff, with less modern things like OpenBSD’s security features, to work on as base Personally, I like to have freedom of choice, so I invite you to package and offer (and keep working) both paxmirabilis and whatever heirloom provides. Your users will thank you.
(In reply to mirabilos from comment #9) once the mir source repo was working & tagged, i was planning on switching Gentoo's pax ebuild to that. the current snapshot is pretty old and its upstream is basically dead (opensuse).
Tested, tagged and published; upload to Debian send to my sponsor. I also created a stub homepage you may use if you want: http://www.mirbsd.org/pax.htm It’s not as nice as mksh’s or jupp’s yet, but can eventually become. This passes all testcases from the Debian bug #774716 for me.
i've added that version now: https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=2a7fdd67e7cae78ef37db299866d810e06b93f3c
OK. I wonder, why do you add <sys/sysmacros.h> and libbsd though? The code compiles on at least GNU/Linux without those. Especially the former, is that something I should add upstream, or is this something left from your previous source that can be removed, or…?
(In reply to mirabilos from comment #13) sys/sysmacros.h should go upstream. the implicit include is being deprecated. this should work on BSD & Linux systems as they both provide this. https://sourceware.org/ml/libc-alpha/2015-11/msg00452.html i have it use libbsd to make it smaller and to re-use existing code. it's better to have a single source to maintain (libbsd) for bugfixes/etc...
OK, this is, again, a lie – <sys/sysmacros.h> is highly unportable and does not even exist on BSD. But since we need it for Linux anyway – I had added it to mksh while porting it to Linux libc5 – i’ve added it, to pax.h, where the Interix equivalent is already included, conditional on -DHAVE_SYS_SYSMACROS_H in CPPFLAGS. When I get around to adding the new build system, detection will become automatic. pax is only tested with the shipped versions of external functions; Guillem’s libbsd is known to sometimes take inferior versions from some BSD variants or even FreeBSD.
is this valid even with app-arch/pax-20161104?
Hmm, https://packages.gentoo.org/packages/app-arch/pax throws an Internal Server Error (500) for me (using lynx as browser)… https://raw.githubusercontent.com/gentoo/gentoo/master/app-arch/pax/pax-20161104.ebuild looks good, and 20161104 addresses CVE-2015-1193 and CVE-2015-1194 plus CVE-2016-6321.
We can stabilize that version then
x86 stable
commit 158975527e77a403c6b42f8fd771fcfcf59441fb Author: Rolf Eike Beer <eike@sf-mail.de> Date: Wed Feb 7 21:06:49 2018 +0100 app-arch/pax: stable 20161104 for sparc, bug #537522
amd64 stable
hppa stable
ia64 stable
ppc/ppc64 stable
Stable on alpha.
arm64 has never had stable keywords on pax, or even ~arm64 keywords. Please pay attention who you CC.
arm stable
GLSA Vote: No tree is clean.
