| Summary: | x11-libs/libX11 XGetPixel() integer overflow (CVE-2007-1667) | ||
|---|---|---|---|
| Product: | Gentoo Security | Reporter: | Sune Kloppenborg Jeppesen (RETIRED) <jaervosz> |
| Component: | Vulnerabilities | Assignee: | Gentoo Security <security> |
| Status: | RESOLVED FIXED | ||
| Severity: | critical | CC: | x11 |
| Priority: | High | ||
| Version: | unspecified | ||
| Hardware: | All | ||
| OS: | Linux | ||
| URL: | https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=231684 | ||
| Whiteboard: | A1 [glsa] jaervosz | ||
| Package list: | Runtime testing required: | --- | |
|
Description
Sune Kloppenborg Jeppesen (RETIRED)
2007-03-30 06:30:49 UTC
x11 please advise. Quoting from http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=414045;msg=85 -- in particular, see the end of this quote for security relevance. "For both the broken.xwd and broken2.xwd files in bug #414045, the offending operation is in libx11-1.0.3/src/ImUtil.c:505 dst++ = *src++; and in fact it's the src pointer that is out of range. This suggests it's "only" a DOS problem, or at worst an information leak problem, but no direct exploit is possible." I'm not sure of the severity but RH states integer overflow and the bug with the patch is restricted (https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=231694) Should we just put it as upstream until more information becomes available (ie. CVE id)? (In reply to comment #3) > Should we just put it as upstream until more information becomes available (ie. > CVE id)? Sure, if you want. But there seems to be a CVE ID in the subject already.. Donnie if you're eager to commit just go ahead, I was just being cautious :) Though CVE ids can be both rejected and contested, so the id in itself doesn't guarantee anything other than giving a common naming system across vendors. Redhat issued an errata here (this also covers the issues from bug #172575): http://rhn.redhat.com/errata/RHSA-2007-0125.html Arches need to stable x11-libs/libX11-1.0.3-r2 or libX11-1.1.1-r1, at their option. libX11-1.1.1-r1.ebuild was recently introduced into ~x86 to do nothing different but additionally apply this patch: xorg-libX11-1.1.1-xinitimage.diff The cvs comment for the change refers to the number of this bug. I had to downdrade to libX11-1.1.1 because this change causes opera to segfault. I recommend *not* stablizing this change. Perhaps this should block on bug #173505. As far as I can see from that bug it's a bug in the client application and not in the patch itself so I suppose we can start marking this one stable. Donnie what do you say? (In reply to comment #10) > As far as I can see from that bug it's a bug in the client application and not > in the patch itself so I suppose we can start marking this one stable. Donnie > what do you say? Agreed. Arches please test and mark stable. Target keywords are: libX11-1.1.1-r1.ebuild:KEYWORDS="alpha amd64 arm hppa ia64 m68k mips ppc ppc64 s390 sh sparc x86 ~x86-fbsd" stable on ppc64: dev-libs/libpthread-stubs-0.1 x11-proto/xcb-proto-1.0 x11-libs/libxcb-1.0 x11-libs/libX11-1.1.1-r1 ditto on amd64 stable on ia64: x11-proto/xcb-proto-1.0 x11-libs/libxcb-1.0 stable on x86 + ia64: x11-libs/libX11-1.1.1-r1 Stable for HPPA. sparc stable. ppc stable alpha done GLSA 200705-06, thanks everybody 1.1.2 is stable for us (at some point) |