Bug 1296102 - (CVE-2016-0718) CVE-2016-0718 expat: Out-of-bounds heap read on crafted input causing crash
CVE-2016-0718 expat: Out-of-bounds heap read on crafted input causing crash
Status: NEW
Product: Security Response
Classification: Other
Component: vulnerability (Show other bugs)
unspecified
All Linux
medium Severity medium
: ---
: ---
Assigned To: Red Hat Product Security
impact=moderate,public=20160517,repor...
: Security
Depends On: 1337117 1337119 1416777 1337115 1337116 1337118 1387550 1387551 1387552 1387553 1387554 1387555 1387556 1387557 1397638 1397639 1397640 1397641
Blocks: 1296104
  Show dependency treegraph
 
Reported: 2016-01-06 05:35 EST by Adam Mariš
Modified: 2017-01-26 06:30 EST (History)
21 users (show)

See Also:
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 04:27 EDT, Adam Mariš
no flags Details | Diff
Updated upstream patch (25.08 KB, patch)
2016-05-20 09:33 EDT, Adam Mariš
no flags Details | Diff
The patch fixing the issue with i686 GoogleEarth (2.53 KB, patch)
2017-01-07 16:15 EST, Dmitry Butskoy
no flags Details | Diff
diffs between original and fixed patches (2.55 KB, patch)
2017-01-07 16:16 EST, Dmitry Butskoy
no flags Details | Diff
complete fixed patch (23.03 KB, patch)
2017-01-07 16:17 EST, Dmitry Butskoy
no flags Details | Diff
original vs.modified patches diffs (3.38 KB, patch)
2017-01-08 17:52 EST, Dmitry Butskoy
no flags Details | Diff

  None (edit)
Description Adam Mariš 2016-01-06 05:35:27 EST
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 10:33:54 EST
Acknowledgments:

Name: Gustavo Grieco
Comment 10 Stefan Cornelius 2016-02-16 10:55:31 EST
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 11:19:38 EST
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 04:27 EDT
Created attachment 1156016 [details]
Upstream patch
Comment 17 Andrej Nemec 2016-05-18 06:43:28 EDT
Created compat-expat1 tracking bugs for this issue:

Affects: fedora-all [bug 1337115]
Comment 18 Andrej Nemec 2016-05-18 06:43:39 EDT
Created expat tracking bugs for this issue:

Affects: fedora-all [bug 1337116]
Comment 19 Andrej Nemec 2016-05-18 06:43:46 EDT
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 06:43:53 EDT
Created expat21 tracking bugs for this issue:

Affects: epel-all [bug 1337117]
Comment 21 Andrej Nemec 2016-05-18 06:44:14 EDT
Public via:

http://seclists.org/oss-sec/2016/q2/360
Comment 22 Adam Mariš 2016-05-20 09:33 EDT
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 18:18:06 EST
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 14:36:15 EST
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-24 19:05:18 EST
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 16:15 EST
Created attachment 1238300 [details]
The patch fixing the issue with i686 GoogleEarth
Comment 39 Dmitry Butskoy 2017-01-07 16:16 EST
Created attachment 1238301 [details]
diffs between original and fixed patches
Comment 40 Dmitry Butskoy 2017-01-07 16:17 EST
Created attachment 1238302 [details]
complete fixed patch
Comment 41 Dmitry Butskoy 2017-01-07 16:18:50 EST
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 17:52 EST
Created attachment 1238499 [details]
original vs.modified patches diffs
Comment 43 Dmitry Butskoy 2017-01-08 18:13:07 EST
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-10 19:55:02 EST
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.

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