Summary: | media-gfx/imagemagick-6.* - XWD Inifinite loop DoS | ||||||
---|---|---|---|---|---|---|---|
Product: | Gentoo Security | Reporter: | Carsten Lohrke (RETIRED) <carlo> | ||||
Component: | Vulnerabilities | Assignee: | Gentoo Security <security> | ||||
Status: | RESOLVED FIXED | ||||||
Severity: | normal | CC: | graphics+disabled, mcummings | ||||
Priority: | High | ||||||
Version: | unspecified | ||||||
Hardware: | All | ||||||
OS: | All | ||||||
Whiteboard: | A3 [glsa] koon | ||||||
Package list: | Runtime testing required: | --- | |||||
Attachments: |
|
Description
Carsten Lohrke (RETIRED)
2005-04-25 12:54:32 UTC
graphics please advise. *** Bug 90479 has been marked as a duplicate of this bug. *** Bumped to 6.2.2.0 in portage Arches please test and mark stable. Note that Perlmagick is now part of Imagemagick so you only need to mark one package stable. stable on ppc64 Stable on alpha + ia64. Stable on amd64 ppc stable Apparently this is not exploitable to execute code so it might be declassified from vulnerability to a simple bug. Waiting as our auditors are busy scouting the code for exploitable ones. Shouldn't the imagemagick ebuild block (using DEPEND) perlmagick instead of doing it in pkg_setup() ?? sparc stable. stable on x86 tester: we want to inform users about this change, perlmagick will be soon removed from portage. Stable on hppa. Imagemagick should block perlmagick in DEPEND not pkg_setup(). See comment 10. iirc, the logic was that we wanted to be able to explain why it was blocked (ie, via some nice ewarns) than merely to show up with a B and no explanation. Taviso/tigger any news on this one? There are a few crashes, but nothing that looks serious yet. There is a DoS in the xwd decoder: in this loop, the mask is set in the image and can be set to zero: 346 /* 347 Determine shift and mask for red, green, and blue. 348 */ 349 red_mask=ximage->red_mask; 350 red_shift=0; 351 while ((red_mask & 0x01) == 0) 352 { 353 red_mask>>=1; 354 red_shift++; 355 } (and the same below for green and blue), which could potentially be a nuisance for web-apps or similar that rely on im for image processing. Arches please mark stable. Created attachment 58154 [details]
xwd DoS testcase
testcase for XWD DoS.
As I understand it, this is NOT fixed by the current release -> back to upstream status. Btw: Taviso, has upstream been notified? PNM Heap overflow is being re-classified as a non-security bug, remaining issue is the xwd DoS. XWD DoS issue fixed in upstream 6.2.2-3 graphics team, please bump imagemagick-6.2.2.3 in portage Arches, please test and mark stable Target KEYWORDS="alpha amd64 hppa ia64 ~mips ppc ppc64 sparc x86" Stable on ppc. (it even fixes those funny colors with import!) Stable on hppa stable on amd64 on x86, I get a sigfpe with the attached test.xwd.. that does not feel ok to me.. SPARC me like a hurricane stable on ppc64 Stable on alpha + ia64. Karol please see comment #29 btw, I get the same result on amd64 as comment #29 The security bug was that processing the testcase image would eat your CPU for a few minutes. If it just crashes, it's no longer an issue... That said, I thought that using Tavis patch it would fail more nicely. [09:26:46] <@taviso> jaervosz: it wasnt my patch, i just reported the issue and suggested catching the condition..that's how upstream fixed it :) sigfpe isnt a security problem, no different from feeding it an invalid image. Not that its a good fix.. but I'm marking stable anyway ;) Ready for a combined GLSA with graphicsmagick GLSA 200505-16 |