Bug 245960 - dev-libs/libxml2 <2.7.2-r1 Integer overflow/infinite loop (CVE-2008-4225, CVE-2008-4226)
|
Bug#:
245960
(CVE-2008-4225)
|
Product: Gentoo Security
|
Version: unspecified
|
Platform: All
|
|
OS/Version: Linux
|
Status: RESOLVED
|
Severity: normal
|
Priority: P2
|
|
Resolution: FIXED
|
Assigned To: security@gentoo.org
|
Reported By: rbu@gentoo.org
|
|
Component: Vulnerabilities
|
|
|
URL:
|
|
Summary: dev-libs/libxml2 <2.7.2-r1 Integer overflow/infinite loop (CVE-2008-4225, CVE-2008-4226)
|
|
Keywords:
|
|
Status Whiteboard: A2 [glsa]
|
|
Opened: 2008-11-07 13:26 0000
|
** Please note that this issue is confidential and no information should be
disclosed until it is made public, see "Whiteboard" for a date **
Drew Yao of Apple Product Security reported two issues in libxml
CVE-2008-4225:
A maliciously crafted xml file could cause the application to go into an
infinite loop, leading to a denial of service. It requires a very
large xml file to trigger the bug, but it's very common to parse
compressed xml files, and the file compresses well.
CVE-2008-4226:
A maliciously crafted xml file could cause an integer overflow leading to
memory corruption and potential arbitrary code execution. It requires a very
large xml file to trigger the bug, but it's very common to parse
compressed xml files, and the file compresses well.
Waiting a bit then for upstream response on the patches before providing a
preebuild. Please let us know if there is any response on that, or feel free to
remind us for a preebuild 4-7 days before confidential end date
And sample compressed XML files would be nice for testing. Attached or sent via
e-mail, as appropriate
Mart, I'll mail it to you.
Created an attachment (id=172041) [details]
Straight-forward preebuild
The first patch is a no-go for me, as even my standard amd64 system doesn't
have SIZE_T_MAX available:
SAX2.c:2459: error: 'SIZE_T_MAX' undeclared (first use in this function)
Nevertheless here's the obvious ebuild that patches those two patches in, so it
can be seen it fails... Note that I intend to rename the patches to include the
version number (${P} instead of ${PN}) in the version that goes into portage
tree once the bugs are disclosed and there's working patches, but don't think I
should hassle the arch teams with renaming the patches as saved off of the
attachments here for that. The end result will have comment in the ebuild
stating what they do as well, once a good description is available from
publicly viewable CVE records.
Any updates, especially for the platform compatibility, from vendor-sec? Though
it shouldn't be hard to fix it ourselves too to compile, but...
This is now public, Daniel Veillard provided more portable patches (which he
probably applied upstream).
libxml2-2.7.2-r1 is in the tree with the patch that was committed upstream,
which is the both combined, plus some extra safeguards for possible future
found problems in parser.c (if I read that right).
Target keywords for dev-libs/libxml2-2.7.2-r1 - everyone:
alpha amd64 arm hppa ia64 m68k ppc ppc64 s390 sh sparch x86
Sparc stable, all tests run successfully.
