Bug#924346: xmltooling: CVE-2019-9628: XML parser class fails to trap exceptions on malformed XML declaration

[wferi at niif.hu]

Salvatore Bonaccorso <carnil at debian.org> writes:

> On Sat, Mar 09, 2019 at 07:25:52PM +0100, wferi at niif.hu wrote:
>
>> I reserved a CVE from Mitre, backported the probable patch to
>> xmltooling 1.6.0-4+deb9u1 in stable and prepared a tentative package
>> with it, please see the debdiff below.  I plan to add more
>> substantive info to the changelog as I get hold of any, but I expect
>> no other changes.
>
> Thanks for preparing the update, the issue is now public, so filled a
> respective Debian bug for it. 

Thanks, Salvatore!

> Were you able to test the resulting package in some extend under
> stretch?

The resulting packages works fine in my setup.  However, I failed to
reproduce the original issue under stretch.  After consulting upstream,
it turns out that the old Xerces library actually helps somewhat in this
case, please see Scott Cantor's reply below.  So the known exploit
(using an invalid XML declaration) does not work on stable, but if
somebody finds a way to trigger a DOMException in Xerces 3.1, any
xmltooling users will crash all the same.  See also his comment on
https://issues.apache.org/jira/browse/XERCESC-2016.

JFYI: we plan to upload the Shibboleth 3 stack to stretch-backports,
which will use the xerces-c 3.2 stretch backport.  These will be fixed
packages, though, in whatever form the Release Team gives its blessing
for.

> I think it sounds sensible to release a DSA for it, so in case yes
> please do upload to security-master (you might add the Debian bug
> closer as well if you need to rebuild and want to add additional
> information).

It will add the closer and the extra information, but won't upload to
security-master unless you tell me so again after reassessing the
situation based on the new information here.

"Cantor, Scott" <cantor.2 at osu.edu> writes:

> Yeah, it's a Xerces change. I didn't make it, but it was applied to
> the trunk as part of XERCES-2016 and there's a very odd change that
> causes the XMLScanner to leak through versions that start with "1." It
> doesn't look correct to me, but it's not for me to say.
>
> Anything up to Xerces 3.1.x catches that and raises the old
> XMLException type that was already caught. Xerces 3.2 ends up with a
> DOMException, which is what caused the crash.
>
> Now: the bug is still a bug. I have no idea under what conditions
> other DOMExceptions could be triggered, and if it happens, you have a
> crash. And the DOMLSParser::parse method is absolutely allowed to
> throw that type of exception, that's in the docs and in the DOM
> standard. But this specific case is only exploitable under Xerces 3.2.
>
> Personally, I would just push the fix and be done with it, it's not a
> hard change, but it's certainly your call. I had to because I require
> Xerces 3.2 at this point in all my packages.
>
> I may update the advisory, but I'm not enthused about overcomplicating
> the message I'm sending with more caveats and conditions.
>
> Good catch though.
>
> -- Scott
-- 
Regards,
Feri