Bug 207396
| Summary: | Crafted tar archive can be used to remove arbitrary files | ||||||
|---|---|---|---|---|---|---|---|
| Product: | Base System | Reporter: | Robert Clausecker <fuz> | ||||
| Component: | misc | Assignee: | freebsd-bugs (Nobody) <bugs> | ||||
| Status: | Closed FIXED | ||||||
| Severity: | Affects Some People | CC: | emaste, kientzle, vsasjason | ||||
| Priority: | --- | ||||||
| Version: | 10.2-RELEASE | ||||||
| Hardware: | Any | ||||||
| OS: | Any | ||||||
| Attachments: |
|
||||||
This has been reported as issue #661 to the libarchive project. https://github.com/libarchive/libarchive/issues/661 Not reproducible for me on 13.0-RC1: $ tar xvf remove.tar x f1: Skipping hardlink pointing to itself: f1 tar: Error exit delayed from previous errors. Oh, I see it was addressed in 3.5.0 and has been merged to stable/11 and stable/12 (but is not in 11.4 or 12.2). Given that the bug was fixed upstream and the upstream version integrated, I suppose the bug can be closed. |
Created attachment 167263 [details] A tar file that removes a file named f1 in badly constructed tar implementations The ustar file format allows to store hard links. Hard links are stored as entries with file type 1 and the linkname field set to the file to link to. In badly constructed tar implementations, a crafted tar file that attempts to link a file to itself can be used to remove files as the tar program first checks if the link-target exists, then unlinks the file name to be linked to and finally attempts to create a link to a non-existent file, which fails for obvious reasons. This attack vector has been known since at least 2003 and is part of the star test suite. FreeBSD tar apparently doesn't contain code to catch this scenario. Instead, it happily deletes files using such crafted archives. This is a potential security problem as tar is not expected to delete files without replacement as it unpacks an archive. Attached is the relevant test case from the star test suite.