New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.

Issue 613575 link

Starred by 2 users

Issue metadata

Status: WontFix
Owner:
Closed: May 2016
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: All
Pri: 1
Type: Bug-Security



Sign in to add a comment

CVE-2016-0718: Expat XML Parser Crashes on Malformed Input

Project Member Reported by infe...@chromium.org, May 20 2016

Issue description

CVE-2016-0718: Expat XML Parser Crashes on Malformed Input
>
> Severity: Critical
>
> Versions Affected: All Expat XML Parser library versions
>
> Description: 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.
>
> Mitigation: Applications that are using Expat should apply the
> attached patch as soon as possible.
>
> Credit: this issue was reported by Gustavo Grieco
>
> and patched by:
>
> * Pascal Cuoq
> * Christian Heimes
> * Karl Waclawek
> * Gustavo Grieco
> * Sebastian Pipping
>
>

Looks like expat guys haven't taken the patch in their repo yet. We need to evaluate if this breaks more stuff.
 
CVE-2016-0718-v2-2-1.patch.txt
25.8 KB View Download
Cc: mbarbe...@chromium.org
It seems expat doesn't have an OWNER in the Chromium repo.
https://chromium.googlesource.com/chromium/src/+log/master/third_party/expat

mbarbella@, you applied a patch a year ago (but not an upstream one?); how do we triage handle patches like this?
Cc: -mbarbe...@chromium.org phoglund@chromium.org
Owner: mbarbe...@chromium.org
Status: Assigned (was: Unconfirmed)
From what I remember, it's been a bit difficult to get patches taken in upstream here. I don't exactly remember why, but I'll give it a shot here. The short answer is that we'll apply the patch in our copy if we have to and make a note in the README.chromium to explain the local modification if necessary.

It really should have an owner, though. I'd rather not be it but I _might_ add myself if I can't get someone else to. If I recall, WebRTC is the biggest user of expat in Chromium. Patrik, is anyone from your team willing to do this?
I don't think so, no. It's used for the libjingle_xmpphelp target which isn't used. Seems to me we should get rid of it and the expat dependency. I have no idea what is was even used for, I guess the google talk plugin back in the day?
Or wait, it's also used by other targets like webrtc/libjingle/xmpp. I'll ask around.
Ok, xmpp are used in src/jingle and src/remoting. I think you want to check with the OWNERS of those things and see what they think.

Comment 6 by aarya@google.com, May 23 2016

Cc: mbarbe...@chromium.org
Owner: sergeyu@chromium.org
Sergeyu@, you seem to have added the libexpat dependencies in libjingle and remoting. Can you get rid of it if it is not used anymore. Libexpat is untested and has ton of security vulnerabilities. Upstream is not accepting patches, so this insecure library we should get rid of. This is security fixit week, your support is appreciated.

Comment 7 by aarya@google.com, May 23 2016

Labels: Security_Impact-Stable OS-All

Comment 8 by aarya@google.com, May 23 2016

Cc: jamiewa...@chromium.org
Project Member

Comment 9 by sheriffbot@chromium.org, May 24 2016

Labels: M-50
Project Member

Comment 10 by sheriffbot@chromium.org, May 26 2016

Labels: -M-50 M-51
Components: Blink>XML Internals
Status: WontFix (was: Assigned)
From Sergey--

 xmllite was in libjingle previously, but now it's part of webrtc, see third_party/webrtc/libjingle/xmllite . Beside Chromoting it's also used by CloudPrint and Sync (though AFAIK Sync depends on it just for tests). In all cases it's used only for XMPP connection to GTalk, so I doubt these vulnerabilities can be exploitable, as the XMPP server validates XML (server side is in Java and doesn't use expat).
To avoid expat dependency xmllite would have to be rewritten to use libxml or something else for XML parsing. I'm not sure if it's something worth spending time on, unless we have exploitable vulnerabilities. XMPP is being deprecated, so all the services will need to migrate off of it at some point. I think we should be able to remove XMPP dependency in Chromoting around Q1 next year. I don't know if CloudPrint team has any work planned for that.

---

Based on that, i am marking this WontFix.
Project Member

Comment 13 by sheriffbot@chromium.org, Sep 7 2016

Labels: -Restrict-View-SecurityTeam
This bug has been closed for more than 14 weeks. Removing security view restrictions.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
Project Member

Comment 14 by sheriffbot@chromium.org, Oct 1 2016

This bug has been closed for more than 14 weeks. Removing security view restrictions.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
Project Member

Comment 15 by sheriffbot@chromium.org, Oct 2 2016

This bug has been closed for more than 14 weeks. Removing security view restrictions.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
Labels: allpublic

Sign in to add a comment