After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 757466 - DoS in libxml2 if xz is enabled
DoS in libxml2 if xz is enabled
Status: RESOLVED FIXED
Product: libxml2
Classification: Platform
Component: general
git master
Other Linux
: Normal normal
: ---
Assigned To: Daniel Veillard
libxml QA maintainers
Depends on:
Blocks:
 
 
Reported: 2015-11-02 11:12 UTC by gustavo.grieco
Modified: 2015-11-03 07:49 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
test case (28 bytes, application/x-xz)
2015-11-02 11:12 UTC, gustavo.grieco
  Details
Initial fix for the issue (501 bytes, patch)
2015-11-02 16:28 UTC, Daniel Veillard
none Details | Review
Patch to re-enable lzma support in head and 2.9.2 (2.74 KB, patch)
2015-11-03 01:54 UTC, Daniel Veillard
none Details | Review

Description gustavo.grieco 2015-11-02 11:12:37 UTC
Created attachment 314626 [details]
test case

Hello,

We found a denegation of service parsing a specially crafted xml in libxml2 if xz support is enabled. Find attached a xml that never finish the parsing process:

gdb --quiet --args xmllint /tmp/test.xz 
Reading symbols from xmllint...(no debugging symbols found)...done.
(gdb) run
Starting program: /usr/bin/xmllint /tmp/test.xz
^C
Program received signal SIGINT, Interrupt.
0xb7f3e63c in xz_decomp (state=state@entry=0x8001cff0) at ../../xzlib.c:509
509	../../xzlib.c: No such file or directory.
(gdb) bt
  • #0 xz_decomp
    at ../../xzlib.c line 509
  • #1 xz_make
    at ../../xzlib.c line 603
  • #2 __libxml2_xzread
    at ../../xzlib.c line 694
  • #3 xmlXzfileRead
    at ../../xmlIO.c line 1421
  • #4 xmlParserInputBufferGrow__internal_alias
    at ../../xmlIO.c line 3317
  • #5 xmlParserInputGrow__internal_alias
    at ../../parserInternals.c line 320
  • #6 xmlGROW
    at ../../parser.c line 2075
  • #7 xmlParseDocument__internal_alias
    at ../../parser.c line 10672
  • #8 xmlDoRead
    at ../../parser.c line 15242
  • #9 ??
  • #10 main

Thanks!
Comment 1 Daniel Veillard 2015-11-02 12:17:44 UTC
   Hi Gustavo,

Switched the bug to private
Hum, I can't reproduce this:

thinkpad2:~/XML -> time /usr/bin/xmllint test.xz
test.xz:1: parser error : Start tag expected, '<' not found


^

real	0m0.001s
user	0m0.000s
sys	0m0.001s
thinkpad2:~/XML -> time ./xmllint test.xz
test.xz:1: parser error : Start tag expected, '<' not found


^

real	0m0.007s
user	0m0.001s
sys	0m0.008s
thinkpad2:~/XML -> 

  what version are you using, on what system ?

BTW I used to be at imag, graduated Ensimag in 92 and PhD at Bull-IMAG thereafter
Comment 2 gustavo.grieco 2015-11-02 13:20:09 UTC
Hello Daniel,

I tested this issue in libxml2-2.9.1 (Ubuntu 14.04 x86 32-bit). Let me know if you cannot reproduce there.

(i'm working for Verimag as a cotutelle phd student in computer security..)
Comment 3 Daniel Veillard 2015-11-02 14:01:26 UTC
I cannot reproduce with released version of 2.9.2 on Fedora nor with git head.

I can reproduce it with libxml2-2.9.1-5.el7_1.2.x86_64 on CentOS 7

I see you posted it to http://seclists.org/oss-sec/2015/q4/206
too.

BTW as a security guy you should not put the test in public directly in
case of severe problems, those are kept under embargo in case it's a real
security issue. And in that case it is a DoS, not nice, if you work in the
field you should know better :-(

Daniel
Comment 4 gustavo.grieco 2015-11-02 14:22:46 UTC
(In reply to Daniel Veillard from comment #3)
> I cannot reproduce with released version of 2.9.2 on Fedora nor with git
> head.
> 
> I can reproduce it with libxml2-2.9.1-5.el7_1.2.x86_64 on CentOS 7

Great!

> 
> I see you posted it to http://seclists.org/oss-sec/2015/q4/206
> too.
> 
> BTW as a security guy you should not put the test in public directly in
> case of severe problems, those are kept under embargo in case it's a real
> security issue. And in that case it is a DoS, not nice, if you work in the
> field you should know better :-(

Yeap, i know about the embargo and that kind of stuff. IMHO, this issue is low priority. In fact, for such bugs, the oss-security list recommends to disclose them to speed-up the fixing process. I posted the test case because people request them all the time for minor issues, even from Red Hat!.

I'm sorry if you think this was a severe issue, if you want i will privately report *all* the issues we found.

> 
> Daniel
Comment 5 Daniel Veillard 2015-11-02 16:28:59 UTC
Created attachment 314670 [details] [review]
Initial fix for the issue
Comment 6 Daniel Veillard 2015-11-03 01:53:14 UTC
For the record in 2.9.2 xz support is somehow broken which is why this is
not reproducible on the latest release and git head, I have a separate patch
to re-enable lzma support (problem introduced by commit f3f86ff465c92c79f834d7b981f3c7274a8bb5c8 for https://bugzilla.gnome.org/show_bug.cgi?id=711026 !)

Daniel
Comment 7 Daniel Veillard 2015-11-03 01:54:21 UTC
Created attachment 314696 [details] [review]
Patch to re-enable lzma support in head and 2.9.2
Comment 8 Daniel Veillard 2015-11-03 07:38:22 UTC
Since the bug was made public on seclist, no embargo, and reopening that bug,

Fixed in https://git.gnome.org/browse/libxml2/commit/?id=f0709e3ca8f8947f2d91ed34e92e38a4c23eae63

  thanks for the report but next time for a DoS, do not disclose it immediately

Daniel
Comment 9 Daniel Veillard 2015-11-03 07:49:09 UTC
Also pushed 18b8988511b0954272cac4d6c3e6724f9dbf6e0a to reenable xz support by
default,

Daniel