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.
Acknowledgments: Name: Gustavo Grieco
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.
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
Created attachment 1156016 [details] Upstream patch
Created compat-expat1 tracking bugs for this issue: Affects: fedora-all [bug 1337115]
Created expat tracking bugs for this issue: Affects: fedora-all [bug 1337116]
Created mingw-expat tracking bugs for this issue: Affects: fedora-all [bug 1337118] Affects: epel-all [bug 1337119]
Created expat21 tracking bugs for this issue: Affects: epel-all [bug 1337117]
Public via: http://seclists.org/oss-sec/2016/q2/360
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.
The customer called the Escalation Hotline to find out what is happening with this BZ. Please get this going!!
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
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
Created attachment 1238300 [details] The patch fixing the issue with i686 GoogleEarth
Created attachment 1238301 [details] diffs between original and fixed patches
Created attachment 1238302 [details] complete fixed patch
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.
Created attachment 1238499 [details] original vs.modified patches diffs
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).
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.
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