|Summary:||CVE-2005-2541 tar: does not properly warn the user when extracting setuid or setgid files|
|Product:||[Other] Security Response||Reporter:||Guilherme de Almeida Suckevicz <gsuckevi>|
|Component:||vulnerability||Assignee:||Red Hat Product Security <security-response-team>|
|Status:||CLOSED WONTFIX||QA Contact:|
|Version:||unspecified||CC:||caswilli, databases-maint, jnakfour, kaycoth, kdudka, odubaj, ovasik, panovotn, pkubat, praiskup, vmugicag|
|Fixed In Version:||Doc Type:||If docs needed, set a value|
|Doc Text:||Story Points:||---|
|Last Closed:||2021-06-28 09:54:06 UTC||Type:||---|
|oVirt Team:||---||RHEL 7.3 requirements from Atomic Host:|
|Cloudforms Team:||---||Target Upstream Version:|
|Bug Depends On:|
Description Guilherme de Almeida Suckevicz 2021-06-21 14:28:44 UTC
Tar 1.15.1 does not properly warn the user when extracting setuid or setgid files, which may allow local users or remote attackers to gain privileges. Reference: http://marc.info/?l=bugtraq&m=112327628230258&w=2
Comment 1 Pavel Raiskup 2021-06-22 09:10:03 UTC
Please provide more details. Do newer tar versions behave better? Do other archives behave better? What is the expected change? When extracting tarball under root, users need to precisely know what they are extracting. There are special notes about this in GNU tar documentation, namely "10.2.3 Dealing with Live Untrusted Data".
Comment 2 Guilherme de Almeida Suckevicz 2021-06-22 13:39:05 UTC
In reply to comment #1: > Please provide more details. Do newer tar versions behave better? > Do other archives behave better? What is the expected change? > > When extracting tarball under root, users need to precisely know > what they are extracting. There are special notes about this > in GNU tar documentation, namely > "10.2.3 Dealing with Live Untrusted Data". This is a very old CVE and I believe it was reported just now. I don't have more details, the only reference available is the one in comment#0. According to that, unzip had a similar issue and there are some discussions whether it's a security vulnerability or not.
Comment 3 Tomas Hoger 2021-06-28 09:54:06 UTC
This issue was reviewed by the Red Hat Security Response Team back when it was originally reported in 2005. This issue was determined to not be a security flaw, but rather the expected behaviour of tar, and the following statement was used: This is the documented and expected behaviour of tar. The GNU tar behaviour when handling archives with setuid or setgit files is as follows: - When ordinary, non-root user extracts such archive, the setuid/setgid bits are not preserved, unless one of the following options is used: -p, --preserve-permissions, --same-permissions - When root user extracts such archive, the setuid/setgid bits are preserved unless the --no-same-permissions option is used. These defaults are only explicitly documented in the 'tar --help' command output as of version 1.16 thanks to the following commit: https://git.savannah.gnu.org/cgit/tar.git/commit/src/tar.c?id=d882e8f39be875b979fbea390d97a9f98566088b This seems to be the reason why these defaults are properly documented in the tar manual page, which has been included upstream as of version 1.28. The tar packages shipped in Red Hat Enterprise Linux 6 and 7 are based on tar versions prior to 1.28, but they do include the manual page with notes on the defaults for the same-permissions option. The defaults do not seem to be documented in the texinfo documentation though. The comment 1 above refers to the "10.2.3 Dealing with Live Untrusted Data" section of the GNU tar documentation, however, the info more relevant to this CVE can rather be found in the "10.2.4 Security Rules of Thumb" section: https://www.gnu.org/software/tar/manual/html_node/Security-rules-of-thumb.html Notably, it notes: """ Extract from an untrusted archive only into an otherwise-empty directory. This directory and its parent should be accessible only to trusted users. """ and """ Do not let untrusted users access files extracted from untrusted archives without checking first for problems such as setuid programs. """ There are currently no code changes planned in response to this 15+ years old CVE.