Bug 206386 - vendor/libarchive: directory traversal vulnerability/local denial of services
Summary: vendor/libarchive: directory traversal vulnerability/local denial of services
Status: Closed FIXED
Alias: None
Product: Base System
Classification: Unclassified
Component: bin (show other bugs)
Version: CURRENT
Hardware: Any Any
: --- Affects Many People
Assignee: Security Team
URL:
Keywords: patch, patch-ready, security
Depends on: 200191
Blocks:
  Show dependency treegraph
 
Reported: 2016-01-18 23:57 UTC by Jason Unovitch
Modified: 2019-03-04 14:20 UTC (History)
4 users (show)

See Also:
junovitch: mfc-stable10?
junovitch: mfc-stable9?


Attachments
vendor/libarchive/dist: Apply CVE-2015-2304 patch (5.83 KB, patch)
2016-01-18 23:57 UTC, Jason Unovitch
no flags Details | Diff
vendor/libarchive/dist: Apply CVE-2013-0211 patch (1.06 KB, patch)
2016-01-19 00:14 UTC, Jason Unovitch
no flags Details | Diff
security/vuxml port: add base to existing libarchive entry (1.13 KB, patch)
2016-01-21 02:28 UTC, Jason Unovitch
no flags Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Jason Unovitch freebsd_committer freebsd_triage 2016-01-18 23:57:27 UTC
Created attachment 165785 [details]
vendor/libarchive/dist: Apply CVE-2015-2304 patch

Affects:  All supported versions of FreeBSD
CVE Name: CVE-2015-2304

Problem Description:
Absolute path traversal vulnerability in bsdcpio in libarchive 3.1.2 and earlier allows remote attackers to write to arbitrary files via a full pathname in an archive. 
 
Impact:
The issue could be exploited to write arbitrary files as the user invoking cpio against a specially crafted cpio archive, which would be leveraged to obtain elevated privileges.

Workaround
No workaround is available, but systems where a privileged user does not
make use of cpio archives without proper validation are not affected.

References:
- https://github.com/libarchive/libarchive/pull/110
- https://github.com/libarchive/libarchive/commit/5935715
- http://www.cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2015-2304



COMMIT LOG FOR ATTACHED PATCH:

Apply upstream changeset 5935715:

Add ARCHIVE_EXTRACT_SECURE_NOABSOLUTEPATHS option
    
This fixes a directory traversal in the cpio tool.

PR: XXXXXX
Security: CVE-2015-2304


Note: I would be more then glad to commit the patch with an 'Approved by' for src and MFV from head/contrib/libarchive with svn merge -c rXXXXXX ^/vendor/libarchive/dist .

EXAMPLE BEFORE:
##### Generate something for the Proof of concept
# echo '*/1 * * * * echo "Do something evil" > /etc/evil.txt' > /var/cron/tabs/root
##### Package it up
# echo '/var/cron/tabs/root' | cpio -ov > test.cpio                                                               
##### Clean up
# rm /var/cron/tabs/root
##### Show it's not there yet
# cat /etc/evil.txt
cat: /etc/evil.txt: No such file or directory
##### Unpackage our "trojaned" file
# cpio -iv < test.cpio 
/var/cron/tabs/root
1 block
##### Show it's in place
# cat /var/cron/tabs/root
*/1 * * * * echo "Do something evil" > /etc/evil.txt
##### Since this didn't update spool dir mtime, be impatient and restart cron to see the impact
# service cron restart
# cat /etc/evil.txt
Do something evil

EXAMPLE AFTER:
##### Unpackage our "trojaned" file
# /usr/local/bin/bsdcpio -iv < test.cpio                                                        
/var/cron/tabs/root
/var/cron/tabs/root: Path is absolute
1 block
##### Show it's in place
# cat /var/cron/tabs/root
cat: /var/cron/tabs/root: No such file or directory

Note, /usr/local/bin/bsdcpio is the patched variant I just committed with the same patch in ports (https://svnweb.FreeBSD.org/changeset/ports/406624).
Comment 1 Jason Unovitch freebsd_committer freebsd_triage 2016-01-19 00:04:42 UTC
Issue #2
Segfault/infinite loop on malformed CPIO archives.  This was patched by delphij@ in head at 282932 [1].  It is in 10.2-RELEASE as part of stable/10 in r283259 [2].  9.3-RELEASE does not seem to be impacted (too old?).  10.1-RELEASE is impacted.  I've validated this in a Poudriere 10.1-RELEASE jail that the base `tar' will spin at 100% CPU while extracting the `crash_dos.tar' available at the upstream bug report [3].  I've also noticed Debian has assigned a temporary bug idea on their security page [4].

It feels like while we are here we can address this in 10.1-RELEASE.

[1] https://svnweb.freebsd.org/base?view=revision&revision=282932
[2] https://svnweb.freebsd.org/base?view=revision&revision=283259
[3] https://github.com/libarchive/libarchive/issues/502
[4] https://security-tracker.debian.org/tracker/TEMP-0784213-45868B


REPLICATION CASES:
##### FreeBSD 101amd64-default 10.1-RELEASE-p27 FreeBSD 10.1-RELEASE-p27 amd64
# tar xvf crash_dos.tar
x .: Can't replace existing directory with non-directory

 3251 root             1  92    0 27804K  2612K RUN     0   1:04  64.36% bsdtar

##### FreeBSD 101i386-default 10.1-RELEASE-p27 FreeBSD 10.1-RELEASE-p27 i386
# tar xvf crash_dos.tar
x .: Can't replace existing directory with non-directory
Fatal Internal Error in libarchive: Negative skip requested.

##### Fixed port
# /usr/local/bin/bsdtar xvf crash_dos.tar                  
x .: Can't replace existing directory with non-directory
bsdtar: End of file trying to read next cpio header
bsdtar: Error exit delayed from previous errors.
Comment 2 Jason Unovitch freebsd_committer freebsd_triage 2016-01-19 00:14:59 UTC
Created attachment 165786 [details]
vendor/libarchive/dist: Apply CVE-2013-0211 patch

Affects:  FreeBSD 9.3
CVE Name: CVE-2015-2304

Mitre's description: Integer signedness error in the archive_write_zip_data function in archive_write_set_format_zip.c in libarchive 3.1.2 and earlier, when running on 64-bit machines, allows context-dependent attackers to cause a denial of service (crash) via unspecified vectors, which triggers an improper conversion between unsigned and signed types, leading to a buffer overflow. 

Discussion:
Fixed in head r248664 (https://svnweb.FreeBSD.org/base?view=revision&revision=248664) which has was part of 10.0-RELEASE.

As this was not properly applied to vendor/libarchive, should the attached patch be applied?  I was confused until I seen that r248664 was a direct commit to head without the MFV the other patches have taken.

I haven't dug into the impact yet past this as this was the last issue I came across and I've already added it to the port.

References: https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2013-0211
Comment 3 Jason Unovitch freebsd_committer freebsd_triage 2016-01-19 00:16:36 UTC
(In reply to Jason Unovitch from comment #1)
Last comment: Add "depends on" closed bug 200191 as that was the original report for the crash/infinite loop issue described in comment 1 that still impacts releng/10.1.
Comment 4 Jason Unovitch freebsd_committer freebsd_triage 2016-01-21 02:28:40 UTC
Created attachment 165895 [details]
security/vuxml port: add base to existing libarchive entry

Draft patch with some "XX"'s to fill in the blanks on entry in https://vuxml.FreeBSD.org/freebsd/7c63775e-be31-11e5-b5fe-002590263bf5.html
Comment 5 Jason Unovitch freebsd_committer freebsd_triage 2016-01-23 23:44:41 UTC
Setting 'patch-ready'... `make universe' was good to go.
Comment 6 Jason Unovitch freebsd_committer freebsd_triage 2016-01-28 02:07:20 UTC
Add to CC; are we going to look at lumping this in with the pre-announced OpenSSL security releases tomorrow?
Comment 7 Jason Unovitch freebsd_committer freebsd_triage 2016-02-28 20:56:08 UTC
libarchive 3.2 with the fixes is due out in mid-March.
https://github.com/libarchive/libarchive/issues/610
Comment 8 Jason Unovitch freebsd_committer freebsd_triage 2016-06-01 00:26:17 UTC
(In reply to Jason Unovitch from comment #0)
CVE-2015-2304 -- https://www.freebsd.org/security/advisories/FreeBSD-SA-16:22.libarchive.asc

(In reply to Jason Unovitch from comment #1)
Never got a CVE

(In reply to Jason Unovitch from comment #2)
CVE-2013-0211 -- https://www.freebsd.org/security/advisories/FreeBSD-SA-16:23.libarchive.asc

@delphij/@secteam feel free to close.
Comment 9 Jason Unovitch freebsd_committer freebsd_triage 2017-11-26 23:11:10 UTC
Fix assignee for review and closure by someone on secteam@.