| Summary: | <app-arch/unace-2.5-r3 : buffer overflows and directory traversal | ||||||
|---|---|---|---|---|---|---|---|
| Product: | Gentoo Security | Reporter: | Sune Kloppenborg Jeppesen (RETIRED) <jaervosz> | ||||
| Component: | Vulnerabilities | Assignee: | Gentoo Security <security> | ||||
| Status: | RESOLVED FIXED | ||||||
| Severity: | major | CC: | andreas.thalhammer, base-system, bircoph, formula7 | ||||
| Priority: | High | ||||||
| Version: | unspecified | ||||||
| Hardware: | All | ||||||
| OS: | All | ||||||
| Whiteboard: | A2 [glsa] | ||||||
| Package list: | Runtime testing required: | --- | |||||
| Bug Depends on: | 214216 | ||||||
| Bug Blocks: | |||||||
| Attachments: |
|
||||||
|
Description
Sune Kloppenborg Jeppesen (RETIRED)
2005-02-13 22:11:52 UTC
CVE ids assigned: CAN-2005-0160 for the buffer overflows. CAN-2005-0161 for the directory traversal problem. There is no metadata.xml so we probably should patch it ourselves. Is 1.2b the only affected version ? There are exactly two unace ebuilds in portage. 1.2b (last free version with source code) and the 2.2 thats a binary only with no source code (no idea if it's vuln or not) needs to be tested with demo file. I do not know why we favor the 2.x binary only package to be stable over the last source code version. But seeing as we have an opensource solution in the tree I'm willing to patch it non the less. unace was first added to gentoo on Oct 28 2002 from bug #9818 s390 can run static ET_EXEC files built on x86? well, if debian has done auditing, does that mean they've developed a patch too ? Created attachment 51628 [details]
unace-info.zip
Sorry. Here is his "attached a ZIP archive containing some test archives
and a patch."
This issue is now public. *** Bug 83057 has been marked as a duplicate of this bug. *** any comments on the patch? if it's sufficient, we should probably apply it couldn't find a bug/patch from debian et al. yet Ok so here is what I know. With the patched unace all the the tests are fine. With the non opensource 2.2 /opt/bin/unace l bufoflow1.ace it attempts to exec a null ptr. options (t l v) with 2.2 PAX: execution attempt in: <NULL>, 00000000-00000000 00000000 PAX: terminating task: /opt/bin/unace(unace):24855, uid/euid: 2600/2600, PC: 55555555, SP: 5eec8214 PAX: bytes at PC: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 grsec: attempted resource overstep by requesting 4096 for RLIMIT_CORE against limit 0 by /opt/bin/unace[unace:24855] uid/euid:2600/2600 gid/egid:2600/2600, parent /bin/bash[bash:15504] uid/euid:2600/2600 gid/egid:2600/2600 unace-1.2b-r1.ebuild in the tree and marked stable for x86. 2.2 remains. Should I p.mask 2.2? I vote for yes. Or even removal of it. Looks like this is ready for GLSA then I guess. solar: I agree, we should mask 2.2 if it is still not 100% fixed, besides that there doesn't seem to be a maintainter anyways. In case of masking 2.2, maybe the GLSA should then mention it. Arch leads. Please read over this and vote on removal/masking of the binary only 2.2 ARCH s390 I have no idea why you have a x86-32 bit binary marked stable on a 31bit arch Can you really do that? The 1.2b is OpenSource From amd64. 28 Feb 2005; Alex Howells <astinus@gentoo.org> unace-1.2b-r1.ebuild: Tested and marked stable on AMD64, reference bug 81958 s390 you no longer have any unace. Removed 1.2b and 2.2 from the tree. Only thing remains is the patched 1.2b Thx everyone. GLSA 200502-32 s390 please remember to mark stable. *unace-2.5 (30 Jan 2007) 30 Jan 2007; Mike Frysinger <vapier@gentoo.org> +unace-2.5.ebuild: Version bump #102347 by Dick Marinus et al. This is *still* vulnerable at least according to Secunia (http://secunia.com/advisories/14359), behaves horribly on the attached test archives (segfaults on bufoflow1.ace, reports broken header on dirtraversal[12].ace) and generally no clue why is it in the tree again. Reopen; someone please verify. /opt/bin/unace v bufoflow1.ace
UNACE v2.5 Copyright by ACE Compression Software Jun 18 2003 22:25:55
Warning: Authenticity verification of archive is broken.
Archive too old or created with non-original program!
Warning: This is not a fully ACE compatible archive.
Trying to decompress might fail.
processing archive /home/aetius/bufoflow1.ace
Warning: Authenticity verification of archive is broken.
Archive too old or created with non-original program!
Warning: This is not a fully ACE compatible archive.
Trying to decompress might fail.
Warning: Authenticity verification of archive is broken.
Archive too old or created with non-original program!
Warning: This is not a fully ACE compatible archive.
Trying to decompress might fail.
created on 0.0.1980 with ver 1.0 by
UUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUU Segmentation fault
********************
warning: shared library handler failed to enable breakpoint
Failed to read a valid object file image from memory.
Core was generated by `/opt/bin/unace v bufoflow1.ace'.
Program terminated with signal 11, Segmentation fault.
#0 0x55555555 in ?? ()
(gdb) info registers
eax 0x0 0
ecx 0x0 0
edx 0x0 0
ebx 0xbf97c094 -1080573804
esp 0xbf97b2a0 0xbf97b2a0
ebp 0x55555555 0x55555555
esi 0xbf97c084 -1080573820
edi 0x3 3
eip 0x55555555 0x55555555
eflags 0x10282 [ SF IF RF ]
cs 0x73 115
ss 0x7b 123
ds 0x7b 123
es 0x7b 123
fs 0x0 0
gs 0x0 0
Verified - EIP is clearly overwritten (along with EBP). Since it's binary and doesn't appear to permit modification, there's nothing we can do with it except mask it and remove it from the tree.
forgot to cc maintainer. :\ there's really nothing we can do about the 2.x series except mask it ... it's a binary-only release Vapier are you OK to p.mask unace-2.5? it doesn't seem to break anything (rox-extra/archive needs app-arch/unace but there is still unace-1 available). i dont know ... unace-1.x cannot handle the new ace archives out there, only unace-2.x can in other words, i'd package mask the whole thing before forcing users to downgrade to a useless version CVE-2007-6563 probably affets this: Heap-based buffer overflow in WinAce 2.65 and earlier, and possibly other versions before 2.69, allows user-assisted remote attackers to execute arbitrary code via a long filename in a compressed UUE archive. There's a new security issue in 2.5, the debian changelog lists a patch:
* debian/patches/11-possibly-critical.dpatch:
+ Fixes a possible security issue by initialising a local variable.
Please note bug 214216 which might help resolve our situation.
unace-2.5-r1 is in the tree with the Debian patchset ... but unace-2.5 was never in stable, so there really wasnt anything there for security to review are there any pending issues for unace-1.2b-r1 ? if not, lets close this bug mmh, I'm not sure what we should do here. I tested unace-2.5-r1 with the .zip attached, no segfault or anything. We could fix the xml to add 2.5-r1 as unaffected, but before that we would need to stable it... security, any opinions? It is rather annoying to have bogus GLSA. As far as I understand 2.5-r1 is not affected by this bug, please fix xml. I've got app-arch/unace-2.5-r2 installed and "glsa-check --test all" still reports GLSA-200502-32 on my system. If unace-2.5-r1 was unaffected already (as suggested by comment #24), the glsa should be fixed accordingly. It doesn't sound very normal that a bug reported in 2005 should still be unfixed in 2013... should stabilize unace-2.5-r3 arm stable amd64 stable Marked ppc/ppc64 stable. Arch teams, please test and mark stable: =app-arch/unace-2.5-r3 Stable KEYWORDS : alpha amd64 arm hppa ppc ppc64 s390 x86 Stable for HPPA. x86 stable alpha stable s390 stable @maintainers: punt affected, timeout 30 days. Maintainer timeout, cleanup + 25 Nov 2013; Sergey Popov <pinkbyte@gentoo.org> -unace-1.2b-r1.ebuild, + -unace-1.2b-r2.ebuild, -files/unace-1.2b-64bit.patch, + -files/unace-1.2b-64bit-fmt.patch, + -files/unace-1.2b-CAN-2005-0160-CAN-2005-0161.patch, + -files/unace-1.2b-aliasing.patch, -unace-2.5.ebuild, -unace-2.5-r1.ebuild, + -unace-2.5-r2.ebuild, -files/unace-2.5-endianness-detection.patch: + Security cleanup, wrt bug #81958 This issue was resolved and addressed in GLSA 200502-32 at http://security.gentoo.org/glsa/glsa-200502-32.xml by GLSA coordinator Sean Amoss (ackle). |
