Bug 1362601 (CVE-2016-5418)

Summary: CVE-2016-5418 libarchive: Archive Entry with type 1 (hardlink), but has a non-zero data size file overwrite
Product: [Other] Security Response Reporter: Kurt Seifried <kseifried>
Component: vulnerabilityAssignee: Red Hat Product Security <security-response-team>
Status: CLOSED ERRATA QA Contact:
Severity: high Docs Contact:
Priority: high    
Version: unspecifiedCC: bleanhar, carnil, ccoleman, dedgar, dmcphers, dmoppert, hhorak, huzaifas, jgoulding, jialiu, jkeck, joelsmith, jokerman, lmeyer, mmccomas, pkubat, praiskup, rhack, sdodson, security-response-team, slawomir, tdawson, todoleza
Target Milestone: ---Keywords: Security
Target Release: ---   
Hardware: All   
OS: Linux   
Fixed In Version: libarchive 3.2.2 Doc Type: If docs needed, set a value
Doc Text:
A flaw was found in the way libarchive handled hardlink archive entries of non-zero size. Combined with flaws in libarchive's file system sandboxing, this issue could cause an application using libarchive to overwrite arbitrary files with arbitrary data from the archive.
Story Points: ---
Clone Of: Environment:
Last Closed: 2019-06-08 02:57:11 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Bug Depends On: 1365774, 1365775, 1365777, 1365778, 1369565, 1369566, 1375280, 1375281, 1375282    
Bug Blocks: 1361631    

Description Kurt Seifried 2016-08-02 15:28:20 UTC
Insomnia Security (as part of a pre-arranged commercial engagement) reports:

A vulnerability in libarchive exists that allows an archive Entry with type 1 (hardlink), but has a non-zero data size to cause a file overwrite. This vulnerability can be leveraged in a way that has a significant security impact (this was not clear at first during initial research by upstream).

Comment 3 Doran Moppert 2016-08-10 07:23:24 UTC
Created attachment 1189473 [details]
patch for all issues against libarchive 3.1.2

Comment 4 Doran Moppert 2016-08-10 07:27:04 UTC
Created attachment 1189474 [details]
patch for all issues against libarchive 2.8.3

Patches against libarchive 3.1.2 (rhel-7) and libarchive 2.8.3 (rhel-6) attached.

Upstream have no timeline for fixing at this point.  The attached patches mitigate the issues on rhel-7/6 but may not be acceptable to upstream in their current form.  We are in contact with the upstream developer and sharing these patches with him, and will attempt to seek a compatible solution which makes rebasing easy against the next upstream release which addresses these flaws.

Comment 7 Doran Moppert 2016-08-12 01:10:06 UTC
Hi Petr,

great to see the patch go into testing so fast.  Is it possible to get PIE enabled in this build?  Using the instructions referenced in comment 5, the following seems to work:

--- a/libarchive.spec
+++ b/libarchive.spec
@@ -89,6 +89,7 @@ Requires:       %{name} = %{version}-%{release}
 The bsdcpio package contains standalone bsdcpio utility split off regular
 libarchive packages.
+%global _hardened_build 1
 %setup -q -n %{name}-%{version}

Checking with commands from sgrubb's rpm-chksec (https://github.com/stevegrubb/security-assessor/):

$ readelf -h bsdtar | grep Type: 
  Type:                              DYN (Shared object file)
$ readelf -d bsdtar | grep '(DEBUG)'
 0x0000000000000015 (DEBUG)              0x0

Comment 8 Doran Moppert 2016-08-12 04:48:59 UTC
Created attachment 1190259 [details]
patch for repro-5 (hardlink to ..) against libarchive 3.1.2

Comment 9 Doran Moppert 2016-08-12 04:51:41 UTC
Created attachment 1190260 [details]
patch for repro-5 (hardlink to ..) against libarchive 2.8.3

Further patches attached (*-patch2.patch).

These address a variation on repro-4 which the previous patch did not include.  They should be applied after the patches 1189473 and 1189474.

Comment 11 Petr Kubat 2016-08-12 07:07:52 UTC
Hi Doran,

Sorry I must have missed your previous comment regarding PIE.
I will enable it in the next build. The patch you have provided in comment 7 seems to do the trick, thanks.

Comment 14 Kurt Seifried 2016-08-25 02:21:20 UTC

Name: Insomnia Security

Comment 17 Kurt Seifried 2016-09-12 15:22:36 UTC
Created libarchive tracking bugs for this issue:

Affects: epel-5 [bug 1375281]
Affects: fedora-all [bug 1375282]

Comment 18 Kurt Seifried 2016-09-12 15:22:48 UTC
Created libarchive3 tracking bugs for this issue:

Affects: epel-6 [bug 1375280]

Comment 19 errata-xmlrpc 2016-09-12 17:35:53 UTC
This issue has been addressed in the following products:

  Red Hat OpenShift Enterprise 3.2

Via RHSA-2016:1853 https://access.redhat.com/errata/RHSA-2016:1853

Comment 20 errata-xmlrpc 2016-09-12 17:36:52 UTC
This issue has been addressed in the following products:

  Red Hat OpenShift Enterprise 3.1

Via RHSA-2016:1852 https://access.redhat.com/errata/RHSA-2016:1852

Comment 21 errata-xmlrpc 2016-09-12 19:57:31 UTC
This issue has been addressed in the following products:

  Red Hat Enterprise Linux 6

Via RHSA-2016:1850 https://rhn.redhat.com/errata/RHSA-2016-1850.html

Comment 22 errata-xmlrpc 2016-09-12 20:16:16 UTC
This issue has been addressed in the following products:

  Red Hat Enterprise Linux 7

Via RHSA-2016:1844 https://rhn.redhat.com/errata/RHSA-2016-1844.html

Comment 23 Doran Moppert 2016-09-13 23:59:11 UTC
Lifted the private flag from patches since this is now fully public.

Upstream has already progressed with committing the forward-ported versions plus further hardening due to Pavel Raiskup to trunk.


Big kudos to Tim Kientzle (upstream) and Pavel Raiskup (red hat) for being a pleasure to work with on these issues.