| Summary: | app-arch/gzip: several issues (CAN-2005-0988, CAN-2005-1228) | ||||||||
|---|---|---|---|---|---|---|---|---|---|
| Product: | Gentoo Security | Reporter: | Sune Kloppenborg Jeppesen (RETIRED) <jaervosz> | ||||||
| Component: | Vulnerabilities | Assignee: | Gentoo Security <security> | ||||||
| Status: | RESOLVED FIXED | ||||||||
| Severity: | normal | ||||||||
| Priority: | High | ||||||||
| Version: | unspecified | ||||||||
| Hardware: | All | ||||||||
| OS: | All | ||||||||
| Whiteboard: | A3? [glsa] jaervosz | ||||||||
| Package list: | Runtime testing required: | --- | |||||||
| Bug Depends on: | |||||||||
| Bug Blocks: | 90626 | ||||||||
| Attachments: |
|
||||||||
|
Description
Sune Kloppenborg Jeppesen (RETIRED)
2005-04-21 10:57:20 UTC
IMHO, both of these vulnerabilities are questionable, the race condition requires improperly set permissions and is of little practical use, if anybody out there really is vulnerable to this and considers it a problem, then they cannot safely use any shell utility that creates or manipulates files (for the same reason mentioned on the other bugs opened in response to Imran's reports). The gunzip --name is a useful feature, I personally have used this in the past. Is it nescessary to cripple it by not allowing a directory to be specified? If you use the gunzip --name, you are explitily stating you dont want gunzip to just use the filename -.gz, you want it to restore the name stored in the gzipped file. If this is considered a vulnerability, then how is specifying a directory any worse than setting the name to .profile? 99% of users are going to gunzip it in their home directory and overwrite their .profile, this is not a problem though as the user has to explicitly requested it to restore the name stored in the file. Removing the ability to save a directory name solves nothing, and cripples the application. I think we should WONTFIX both of these. (btw, we are affected) mmm i think you missed a few things to note ... if you do this: # touch /etc/nologin # gzip /etc/nologin # mv /etc/nologin.gz someevil.gz # gunzip -N someevil.gz you will end up with $PWD/nologin, not with /etc/nologin ... gzip does not store paths in its name however if you craft a gzipped file whose 'name' is /etc/nologin, when you use -N, the result will create /etc/nologin ... in other words, by adding checks for '/' in the filename, we're not crippling gzip's normal functionality Vapier: I stand corrected, i consulted RFC1952 and it states "This is the original name of the file being compressed, with any directory components removed", so users could have an understandable belief that this wouldnt happen. Created attachment 56955 [details, diff]
gzip-1.3.5-dir-trav.patch
original patch suggested by Ulf in the debian report caused proper behavior to
misfunction
i wrote a new patch which adds logic inside of the code which parses the name
in the gzip header ... seems to fix the issue for me, please review
tigger, taviso, solar please review patch. The patch is OK, but considering this a security bug may be overkill : people uncompressing as root with -N without testing first have no clue anyway... What's the opinion of the other security guys ? i wouldnt say that ... if root is in their ~/ then one would expect gzip to extract to $PWD regardless I still think you want to send your patch to Ulf Harnhammar the deb guy for input. I cant really comment on the patch if it does the right thing or not. spankys patches are usually good so it probably can/should work it's way into ~arch Created attachment 57510 [details, diff]
gzip.dirtraversal_better.patch
Revised patch by Ulf Harnhammar for the directory traversal vulnerability.
Response from Ulf: I tested it and looked at it, and it seems to work. You avoid the base_name() and strcpy() calls from my second patch, so it might even be a better solution. // Ulf doesnt matter to me which patch goes in as long as they both are documented ... anyone else care ? ah well redhat/fedora went with the base_name/strcpy so we might as well to play along gzip-1.3.5-r6 now in portage with the fix Thx SpanKY. Arches please test and mark stable. Note that m68k is not CC'ed as they don't have a valid Bugzilla account. Someone(vapier?) please fix that. stable on amd64 sparc stable. ppc64 stable x86 stable Stable on ppc. Stable on hppa. Stable on alpha + ia64. arm/s390 stable mips stable. GLSA 200505-05 |