Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 537522 (CVE-2015-1193, CVE-2015-1194) - <app-arch/pax-20161104: directory traversal
Summary: <app-arch/pax-20161104: directory traversal
Status: RESOLVED FIXED
Alias: CVE-2015-1193, CVE-2015-1194
Product: Gentoo Security
Classification: Unclassified
Component: Vulnerabilities (show other bugs)
Hardware: All Linux
: Normal minor (vote)
Assignee: Gentoo Security
URL: http://www.openwall.com/lists/oss-sec...
Whiteboard: B4 [noglsa cve]
Keywords:
Depends on:
Blocks:
 
Reported: 2015-01-24 09:37 UTC by Agostino Sarubbo
Modified: 2018-03-29 00:07 UTC (History)
4 users (show)

See Also:
Package list:
app-arch/pax-20161104
Runtime testing required: ---
stable-bot: sanity-check+


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Agostino Sarubbo gentoo-dev 2015-01-24 09:37:51 UTC
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.
Comment 1 GLSAMaker/CVETool Bot gentoo-dev 2015-06-15 00:54:02 UTC
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.
Comment 2 Yury German Gentoo Infrastructure gentoo-dev Security 2015-11-25 04:33:59 UTC
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?
Comment 3 Kerin Millar 2016-02-26 22:03:04 UTC
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.
Comment 4 SpanKY gentoo-dev 2016-02-28 05:51:13 UTC
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 ?
Comment 5 Thorsten Glaser 2016-03-04 23:09:55 UTC
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 ☹
Comment 6 SpanKY gentoo-dev 2016-03-05 05:30:32 UTC
(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.
Comment 7 mirabilos 2016-03-05 15:36:39 UTC
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.
Comment 8 SpanKY gentoo-dev 2016-03-05 16:35:33 UTC
(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 :/
Comment 9 mirabilos 2016-03-05 23:41:46 UTC
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.
Comment 10 SpanKY gentoo-dev 2016-03-06 03:25:18 UTC
(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).
Comment 11 mirabilos 2016-03-06 23:03:31 UTC
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.
Comment 13 mirabilos 2016-03-07 21:24:00 UTC
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…?
Comment 14 SpanKY gentoo-dev 2016-03-07 22:45:20 UTC
(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...
Comment 15 mirabilos 2016-03-12 20:55:27 UTC
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.
Comment 16 Pacho Ramos gentoo-dev 2018-02-06 19:40:33 UTC
is this valid even with app-arch/pax-20161104?
Comment 17 mirabilos 2018-02-06 20:49:03 UTC
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.
Comment 18 Pacho Ramos gentoo-dev 2018-02-06 21:54:55 UTC
We can stabilize that version then
Comment 19 Thomas Deutschmann gentoo-dev Security 2018-02-07 06:10:01 UTC
x86 stable
Comment 20 Sergei Trofimovich gentoo-dev 2018-02-07 20:17:53 UTC
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
Comment 21 Agostino Sarubbo gentoo-dev 2018-02-09 08:39:43 UTC
amd64 stable
Comment 22 Sergei Trofimovich gentoo-dev 2018-02-10 20:53:31 UTC
hppa stable
Comment 23 Sergei Trofimovich gentoo-dev 2018-02-18 19:49:20 UTC
ia64 stable
Comment 24 Sergei Trofimovich gentoo-dev 2018-02-27 20:31:43 UTC
ppc/ppc64 stable
Comment 25 Tobias Klausmann gentoo-dev 2018-03-02 15:59:55 UTC
Stable on alpha.
Comment 26 Mart Raudsepp gentoo-dev 2018-03-03 01:55:57 UTC
arm64 has never had stable keywords on pax, or even ~arm64 keywords. Please pay attention who you CC.
Comment 27 Markus Meier gentoo-dev 2018-03-06 19:37:49 UTC
arm stable
Comment 28 Markus Meier gentoo-dev 2018-03-13 17:39:11 UTC
arm stable
Comment 29 Markus Meier gentoo-dev 2018-03-13 17:51:22 UTC
arm stable
Comment 30 Aaron Bauman Gentoo Infrastructure gentoo-dev Security 2018-03-29 00:07:57 UTC
GLSA Vote: No

tree is clean.