This service will be undergoing maintenance at 00:00 UTC, 2017-10-23 It is expected to last about 30 minutes
Bug 1264928 - rpm will install and leave files when installing specifically tampered packages, circumventing package signing protection
rpm will install and leave files when installing specifically tampered packag...
Status: NEW
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: rpm (Show other bugs)
7.1
All Linux
unspecified Severity high
: rc
: ---
Assigned To: Florian Festi
BaseOS QE Security Team
: Security
Depends On:
Blocks: 1380360
  Show dependency treegraph
 
Reported: 2015-09-21 12:49 EDT by Alex deVries
Modified: 2017-09-27 23:23 EDT (History)
7 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed:
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
Tampered RPM that shows this defect. (66.56 KB, application/x-rpm)
2015-09-21 12:49 EDT, Alex deVries
no flags Details

  None (edit)
Description Alex deVries 2015-09-21 12:49:32 EDT
Created attachment 1075527 [details]
Tampered RPM that shows this defect.

Description of problem
----------------------

RPM has a defect where it will leave some files behind when installing a specifically tampered RPM. Unlike in 2014-6534, these files are never erased.

This works whether the package is signed or not, and the user is not informed that it is improperly signed.

One can only exploit this vulnerability by using tampered packages that were previously signed. This bug does not make it possible to install files with arbitrary code. However, it is possible to disable existing services by only partially installing the files of a package.

The user is never properly informed that the signing fails.

Version-Release number of selected component (if applicable):
------------------------------------------------------------

- seen on Red Hat EL 7.1 and other RPM-based distributions, but appears to be in versions of rpm 4.9.1.3 to 4.11.1-25 and maybe later.


Steps to Reproduce:
-------------------

The tampered package used as an example here is mcelog-101-3.9de4924.el7.x86_64.rpm, but it's reproducible with various packages.

# 1. Notice that the original package is valid and installs properly

[adevries@redhat7 ~]$ rpm -Kv mcelog-101-3.9de4924.el7.x86_64.rpm 
mcelog-101-3.9de4924.el7.x86_64.rpm:
    Header V3 RSA/SHA256 Signature, key ID fd431d51: OK
    Header SHA1 digest: OK (d82045392a327b7fc0c82a473387869316d8d5c6)
    V3 RSA/SHA256 Signature, key ID fd431d51: OK
    MD5 digest: OK (761800f3cfaac7ac163ec215d1536dc7)

[adevries@redhat7 ~]$ sudo rpm -Uvh mcelog-101-3.9de4924.el7.x86_64.rpm 
Preparing...                          ################################# [100%]
Updating / installing...
   1:mcelog-3:101-3.9de4924.el7       ################################# [100%]

[adevries@redhat7 ~]$ sudo rpm --erase mcelog

2. Notice that none of the package's files are on the filesystem

[adevries@redhat7 ~]$ rpm -qlp mcelog-101-3.9de4924.el7.x86_64.rpm  | xargs ls -l 
ls: cannot access /etc/cron.hourly/mcelog.cron: No such file or directory
ls: cannot access /etc/mcelog: No such file or directory
ls: cannot access /etc/mcelog/mcelog.conf: No such file or directory
...


3. Tamper the package
a) Split the original RPM binary between the header and the payload by splitting on the xz magic (0xfd377a58). Keep the header intact.
b) Unxz the payload to get a cpio archive
c) Change any character in the first file in the archive you wish to skip. That file and all subsequent files will not be installed. If you want all the files, tamper the final "TRAILER!!!" string in the archive.
d) compress the archive with xz, append it to the header and this will give you the tampered package

In the attached example tampered package, the file /usr/share/doc/mcelog-101/README was changed.

4. Install the tampered package

# Notice the tampered package's payload doesn't pass the signature or MD5 (as expected)
[adevries@redhat7 ~]$ rpm -Kv tampered-mcelog-101-3.9de4924.el7.x86_64.rpm 
tampered-mcelog-101-3.9de4924.el7.x86_64.rpm:
    Header V3 RSA/SHA256 Signature, key ID fd431d51: OK
    Header SHA1 digest: OK (d82045392a327b7fc0c82a473387869316d8d5c6)
    V3 RSA/SHA256 Signature, key ID fd431d51: BAD
    MD5 digest: BAD Expected(761800f3cfaac7ac163ec215d1536dc7) != (a00e2d5d943775ec1ec39a10568f95f6)

# Install the package

@redhat7 ~]$ sudo rpm -Uvh tampered-mcelog-101-3.9de4924.el7.x86_64.rpm 
[sudo] password for adevries: 
Preparing...                          ################################# [100%]
Updating / installing...
   1:mcelog-3:101-3.9de4924.el7       ################################# [100%]
error: unpacking of archive failed on file /usr/share/doc/mcelog-101/README;55fda249: cpio: Digest mismatch

:error: mcelog-3:101-3.9de4924.el7.x86_64: install failed.


Actual results
--------------
# Notice only some of the files remain

[adevries@redhat7 ~]$ rpm -qlp tampered-mcelog-101-3.9de4924.el7.x86_64.rpm | xargs -n1 ls -l 
-rwxr-xr-x. 1 root root 191 Oct 30  2014 /etc/cron.hourly/mcelog.cron
total 12
-rw-r--r--. 1 root root 1597 Oct 30  2014 mcelog.conf
-rwxr-xr-x. 1 root root  445 Oct 30  2014 mcelog.setup
drwxr-xr-x. 2 root root 4096 Sep 19 13:58 triggers
-rw-r--r--. 1 root root 1597 Oct 30  2014 /etc/mcelog/mcelog.conf
-rwxr-xr-x. 1 root root 445 Oct 30  2014 /etc/mcelog/mcelog.setup
total 16
-rwxr-xr-x. 1 root root 1035 Oct 30  2014 cache-error-trigger
-rwxr-xr-x. 1 root root 1213 May 15  2013 dimm-error-trigger
-rwxr-xr-x. 1 root root 1308 May 15  2013 page-error-trigger
-rwxr-xr-x. 1 root root 1057 May 15  2013 socket-memory-error-trigger
-rwxr-xr-x. 1 root root 1035 Oct 30  2014 /etc/mcelog/triggers/cache-error-trigger
-rwxr-xr-x. 1 root root 1213 May 15  2013 /etc/mcelog/triggers/dimm-error-trigger
-rwxr-xr-x. 1 root root 1308 May 15  2013 /etc/mcelog/triggers/page-error-trigger
-rwxr-xr-x. 1 root root 1057 May 15  2013 /etc/mcelog/triggers/socket-memory-error-trigger
-rw-r--r--. 1 root root 585 Oct 30  2014 /usr/lib/systemd/system/mcelog.service
-rwxr-xr-x. 1 root root 113184 Oct 30  2014 /usr/sbin/mcelog
total 8
-rw-r--r--. 1 root root 4859 May 15  2013 CHANGES
-rw-r--r--. 1 root root 4859 May 15  2013 /usr/share/doc/mcelog-101/CHANGES
ls: cannot access /usr/share/doc/mcelog-101/README: No such file or directory
ls: cannot access /usr/share/man/man8/mcelog.8.gz: No such file or directory

----------------

One would expect:
- a notice that the package had failed validation
- no files from the package would have been copied to the filesystem, or they would have been erased


Additional info
---------------

At first I thought this was related to CVE 2014-6354, but I don't think so because:
- it is present in RHEL 7.1 and versions of rpm up to at least 4.13.0, which has had that CVE addressed
- the files left installed are not marked as temporary files, are retained and have correct permissions

Things that did not work:
- changing the contents of a file; tampered files just didn't install. This prevents arbitrary code execution.
- changing the length of a file

Some other things that worked:

- package update works, replacing only some of the files (although the error shown is "erase skipped", which is clearer)

- normally, the installation of files ends whenever corruption of the cpio archive is tampered. However, the hacker can install the files he wants by just reordering the files within the cpio archive

The possible impacts could be:

- partially upgrading a package could result in a service not working (DoS), eg. replacing a binary and not its dependant libraries

- install files of a package but not its associated policies that restrict its function. This would be hard to find.

A hacker would have more time than me.. I haven't generated a patch. There are other things to look at (can one replace a %config file? do the %preinst scripts get run? are there other ways to change a file? what happens with file dependencies and something like yum or dnf?).

Regardless, this compromises the effectiveness of package signing.

Note You need to log in before you can comment on or make changes to this bug.