Bug 1296102 (CVE-2016-0718) - CVE-2016-0718 expat: Out-of-bounds heap read on crafted input causing crash
Summary: CVE-2016-0718 expat: Out-of-bounds heap read on crafted input causing crash
Status: NEW
Alias: CVE-2016-0718
Product: Security Response
Classification: Other
Component: vulnerability   
(Show other bugs)
Version: unspecified
Hardware: All Linux
medium
medium
Target Milestone: ---
Assignee: Red Hat Product Security
QA Contact:
URL:
Whiteboard: impact=moderate,public=20160517,repor...
Keywords: Security
Depends On: 1337117 1337119 1416777 1512373 1512374 1337115 1337116 1337118 1387550 1387551 1387552 1387553 1387554 1387555 1387556 1387557 1397638 1397639 1397640 1397641
Blocks: 1296104
TreeView+ depends on / blocked
 
Reported: 2016-01-06 10:35 UTC by Adam Mariš
Modified: 2018-10-19 21:36 UTC (History)
50 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
An out-of-bounds read flaw was found in the way Expat processed certain input. A remote attacker could send specially crafted XML that, when parsed by an application using the Expat library, would cause that application to crash or, possibly, execute arbitrary code with the permission of the user running the application.
Story Points: ---
Clone Of:
Environment:
Last Closed:
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
Upstream patch (25.00 KB, patch)
2016-05-11 08:27 UTC, Adam Mariš
no flags Details | Diff
Updated upstream patch (25.08 KB, patch)
2016-05-20 13:33 UTC, Adam Mariš
no flags Details | Diff
The patch fixing the issue with i686 GoogleEarth (2.53 KB, patch)
2017-01-07 21:15 UTC, Dmitry Butskoy
no flags Details | Diff
diffs between original and fixed patches (2.55 KB, patch)
2017-01-07 21:16 UTC, Dmitry Butskoy
no flags Details | Diff
complete fixed patch (23.03 KB, patch)
2017-01-07 21:17 UTC, Dmitry Butskoy
no flags Details | Diff
original vs.modified patches diffs (3.38 KB, patch)
2017-01-08 22:52 UTC, Dmitry Butskoy
no flags Details | Diff


External Trackers
Tracker ID Priority Status Summary Last Updated
Red Hat Product Errata RHSA-2016:2824 normal SHIPPED_LIVE Moderate: expat security update 2016-11-29 00:35:53 UTC
Red Hat Product Errata RHSA-2018:2486 None None None 2018-08-16 16:06 UTC

Description Adam Mariš 2016-01-06 10:35:27 UTC
The Expat XML parser mishandles certain kinds of malformed input documents, resulting in buffer overflows during processing and error reporting. The overflows can manifest as a segmentation fault or as memory corruption during a parse operation. The bugs allow for a denial of service attack in many applications by an unauthenticated attacker, and could conceivably result in remote code execution.

Comment 2 Adam Mariš 2016-01-06 15:33:54 UTC
Acknowledgments:

Name: Gustavo Grieco

Comment 10 Stefan Cornelius 2016-02-16 15:55:31 UTC
Thank you very much for your excellent work!

Sorry, I should really have seen your comments earlier but I haven't - a misunderstanding between me and my email filtering.

Indeed, python is problematic here. Does python upstream have a release date yet? I'll whip this bug into good shape tomorrow-ish and check if we can prepare updates.

Comment 11 Christian Heimes 2016-02-16 16:19:38 UTC
Avahi also uses expat. It runs on most workstations + laptops and listens on network connections. I'm not familiar with ZeroConf, does it use XML for communication?

We are currently preparing a new release of Python 2.7 to 3.5 with three security fixes. One fix is still under development. Since Python ships its own copy of expat and uses the copy on Windows, I'd appreciate a coordinated release of the expat fix. It's going to take a week or two to prepare the releases on your side.

By the way I ran into trouble with expat's outdated autoconf / automake files. I hacked and messed around with the files until autoconf worked again for me: https://github.com/tiran/expat/commit/9c6ca6b0ae8a7c13153fdd48b5360988c2fdae80

Comment 16 Adam Mariš 2016-05-11 08:27 UTC
Created attachment 1156016 [details]
Upstream patch

Comment 17 Andrej Nemec 2016-05-18 10:43:28 UTC
Created compat-expat1 tracking bugs for this issue:

Affects: fedora-all [bug 1337115]

Comment 18 Andrej Nemec 2016-05-18 10:43:39 UTC
Created expat tracking bugs for this issue:

Affects: fedora-all [bug 1337116]

Comment 19 Andrej Nemec 2016-05-18 10:43:46 UTC
Created mingw-expat tracking bugs for this issue:

Affects: fedora-all [bug 1337118]
Affects: epel-all [bug 1337119]

Comment 20 Andrej Nemec 2016-05-18 10:43:53 UTC
Created expat21 tracking bugs for this issue:

Affects: epel-all [bug 1337117]

Comment 21 Andrej Nemec 2016-05-18 10:44:14 UTC
Public via:

http://seclists.org/oss-sec/2016/q2/360

Comment 22 Adam Mariš 2016-05-20 13:33 UTC
Created attachment 1159904 [details]
Updated upstream patch

The patch was updated due to undefined behavior when computing larger blockSize and some signed integer overflows were fixed.

Comment 27 Dana Safford 2016-11-17 23:18:06 UTC
The customer called the Escalation Hotline to find out what is happening with this BZ.

Please get this going!!

Comment 36 errata-xmlrpc 2016-11-28 19:36:15 UTC
This issue has been addressed in the following products:

  Red Hat Enterprise Linux 7
  Red Hat Enterprise Linux 6

Via RHSA-2016:2824 https://rhn.redhat.com/errata/RHSA-2016-2824.html

Comment 37 Dmitry Butskoy 2016-12-25 00:05:18 UTC
Regression found with an external product on RHEL6, after updating 
from expat-2.0.1-11.el6 to expat-2.0.1-13.el6:

GoogleEarth, version of 6.2.2.6613

(it is an old version, still i686, runing on x86_64, because newer versions have unresolved dependencies on RHEL6).

After update to expat-2.0.1-13.el6_8.i686, googleearth crashes at startup with message:

> Fatal error in __driConfigOptions line 1, column 0: out of memory.
> Google Earth has caught signal 6.
>
>
>
> We apologize for the inconvenience
...snip...

The first line is a report from /usr/lib/libGL.so.1 library.

Mesa code use some xml data in a form of hardcoded strings in various binaries, including /usr/lib/dri/*_dri.so drivers, as well as /usr/lib/libGL.so.1 itself (search the binary for <driinfo>, for example). It seems that expat is used to parse such data.
Probably, after the update, something goes wrong with such cases.

The only interesting thing from strace is:

> mmap2(NULL, 135168, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xfffffffff6634000
> mremap(0xf6634000, 135168, 266240, MREMAP_MAYMOVE) = 0xfffffffff4527000
> mremap(0xf4527000, 266240, 528384, MREMAP_MAYMOVE) = 0xfffffffff1e5e000
> mremap(0xf1e5e000, 528384, 1052672, MREMAP_MAYMOVE) = 0xffffffffeb211000
> mremap(0xeb211000, 1052672, 2101248, MREMAP_MAYMOVE) = 0xffffffffeb010000
> mremap(0xeb010000, 2101248, 4198400, MREMAP_MAYMOVE) = 0xffffffffeac0f000
> mremap(0xeac0f000, 4198400, 8392704, MREMAP_MAYMOVE) = 0xffffffffea40e000
> mremap(0xea40e000, 8392704, 16781312, MREMAP_MAYMOVE) = 0xffffffffe940d000
> mremap(0xe940d000, 16781312, 33558528, MREMAP_MAYMOVE) = 0xffffffffe740c000
> mremap(0xe740c000, 33558528, 67112960, MREMAP_MAYMOVE) = 0xffffffffe340b000
> mremap(0xe340b000, 67112960, 134221824, MREMAP_MAYMOVE) = 0xffffffffdb40a000
> mremap(0xdb40a000, 134221824, 268439552, MREMAP_MAYMOVE) = 0xffffffffcb409000
> mremap(0xcb409000, 268439552, 536875008, MREMAP_MAYMOVE) = 0xffffffffab408000
> mremap(0xab408000, 536875008, 1073745920, MREMAP_MAYMOVE) = 0x6b407000
> mremap(0x6b407000, 1073745920, 2147487744, MREMAP_MAYMOVE) = -1 ENOMEM (Cannot allocate memory)
> mmap2(NULL, 2147487744, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = -1 ENOMEM (Cannot allocate memory)
> mmap2(NULL, 2147618816, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = -1 ENOMEM (Cannot allocate memory)
> mmap2(NULL, 2097152, PROT_NONE, MAP_PRIVATE|MAP_ANONYMOUS|MAP_NORESERVE, -1, 0) = 0xffffffffeb112000
> munmap(0xeb112000, 974848)        = 0
> munmap(0xeb300000, 73728)         = 0
> mprotect(0xeb200000, 135168, PROT_READ|PROT_WRITE) = 0
> mmap2(NULL, 2147487744, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = -1 ENOMEM (Cannot allocate memory)
> write(2, "Fatal error in __driConfigOption"..., 67) = 67

Comment 38 Dmitry Butskoy 2017-01-07 21:15 UTC
Created attachment 1238300 [details]
The patch fixing the issue with i686 GoogleEarth

Comment 39 Dmitry Butskoy 2017-01-07 21:16 UTC
Created attachment 1238301 [details]
diffs between original and fixed patches

Comment 40 Dmitry Butskoy 2017-01-07 21:17 UTC
Created attachment 1238302 [details]
complete fixed patch

Comment 41 Dmitry Butskoy 2017-01-07 21:18:50 UTC
Some investigations:

Altering the patch a little resolves the issue (see attachments).

Looks strange, but probably it might be some side effects of the running 32-bit application under 64-bit environment...

Could anybody look on it further?

(For best visibility, see attachment 1238301 [details] for diffs of the patches.)


BTW, the latest upstream 2.2.0 (with all security patches applied etc.) has the issue as well.

Comment 42 Dmitry Butskoy 2017-01-08 22:52 UTC
Created attachment 1238499 [details]
original vs.modified patches diffs

Comment 43 Dmitry Butskoy 2017-01-08 23:13:07 UTC
Well,

consider the original and modified patches changes in attachment 1238499 [details] .

The original patch implements a returned value for function XmlConvert().

Actually, XmlConvert is a macro, which finally expanded either to (enc->utf8Convert) or (enc->utf16Convert) .

The problem seems to be that enc->utf8Convert or env->utf16Convert might be initialized externally -- and an application which doing such an init by its own way can still knows nothing that these methods now must return a value.

Probably GoogleEarth version 6 behaves so. I see a lot of calls to XmlConvert() which returns random values (as usual for void/integer misbehavior).


IOW, applying the current CVE-2016-0718 security patch can break third party utf{8,16}Convert functions, which can lead to the random returned value.
(Upstream 2.2.0 has the issue as well).

Comment 44 Dmitry Butskoy 2017-01-11 00:55:02 UTC
GoogleEarth 6 has duplications of some 'Xml*' symbols -- the same provided both by GE and by the system libexpat.so.1 . It leads to misbehavior.

The simple working solution for GE 6 is just to use "LD_PRELOAD=/lib/libexpat.so.1", to avoid linking of system libraries with GE binaries. OTOH this way GE binaries link with the system one instead of its own (don't know what happens here exactly, but GE works).


It seems that previous reports about broken patch look like a noise. :( Sorry.

Comment 49 errata-xmlrpc 2018-08-16 16:06:24 UTC
This issue has been addressed in the following products:

  Red Hat JBoss Core Services

Via RHSA-2018:2486 https://access.redhat.com/errata/RHSA-2018:2486


Note You need to log in before you can comment on or make changes to this bug.