FasterXML/woodstox

Unlimited recursion for DTD parsing

StefanSchrass opened this issue · 19 comments

StefanSchrass commented

I just got notified that:

Library Security Vulnerabilities (woodstox-core-6.3.1.jar, Total: 6) | 2022-09-22

CVE-2022-40155 (Severity: High)
CVE-2022-40154 (Severity: High)
CVE-2022-40156 (Severity: High)
CVE-2022-40151 (Severity: High)
CVE-2022-40153 (Severity: High)
CVE-2022-40152 (Severity: High)

cowtowncoder commented

WTF. Any info on what those are? No one has contacted me.

StefanSchrass commented

This notification is from our projects whitesource check.
As far as I can tell the vulnerabilities do not leak sensitive information, but do allow for DOS attacks.

As I use it in a controlled environment, my concern is mainly about whitesource freaking out and security folks asking when the issue will be resolved.

cowtowncoder commented

@StefanSchrass At this point I don't have time to go looking for issues, so someone should explain exactly what is supposed to be the problem; maybe go via Tidelift security contact OR email me to my fasterxml email address (tatu at fasterxml dot com).

A smaller think that'd help would be linking to CVE description, although maybe actual description are not yet open to public.

I really think it's a particularly shitty thing to file for an CVE before contacting library author; not sure if that's what happened here but certainly smells like that. If so, shame on people filing these.

cowtowncoder commented

Huh?

https://nvd.nist.gov/vuln/detail/CVE-2022-40151

is for XStream NOT Woodstox.

It also seems to be from questionable source:

x-stream/xstream#304

so... I don't think I should spend any time yet until something tangible is reported.

StefanSchrass commented

I think the problem is centered around woodstox-core is using Xstream.
CVE-2022-40155

StefanSchrass commented

This is nuts.
I hope you made yourself clear on xstream.

And I do hope that database gets updated.

cowtowncoder commented

Yeah, I am really unhappy about some of security research activity around OSS.

Also forgot: thank you @StefanSchrass for bringing this to my attention. I did not mean to direct my frustration towards you, just in case that was not clear.

  • 👍5
0roman commented

hi @cowtowncoder, do you want to be added temporarily as receiver for the xstream bugs in oss-fuzz. This would grant you with access to the stacktraces and crashing inputs. I could point you to the few issues that might be related to woodstox. Sorry for the inconvenience.

cowtowncoder commented

@0roman Thank you for the offer but I don't think I have to time to pro-actively dig into issues here, due to overload with many other things (I get reports for all Jackson-related fuzzers and one Woodstox one), as well as not being familiar with XStream codebase these days.

To work on Woodstox issues the problem would need to be isolated anyway, and I think security researchers would be in a good position to do that; once more isolated examples exist I would definitely help in figuring out what is going on.

I appreciate your reaching out, I hope we can figure out the issues.

0roman commented

@cowtowncoder okay, I completely understand that.

I am also not really familiar with XStream yet, however I have spend some time going quickly over those issues in OSS-Fuzz. I have observed that readContenSpec in woodstox class FullDTDReader

woodstox/src/main/java/com/ctc/wstx/dtd/FullDTDReader.java

Line 3050 in b8f136b

private ContentSpec readContentSpec(PrefixedName elemName, boolean mainLevel,
is called recursively some hundred times before leading to the stackoverflows in all issues. From the code it looks like that every new bracket "(" might call readContentSpec recursively. The crashing inputs are also indicating that XML documents that are containing some hundred open brackets but no closed one may reproduce that issue, such as
malformed_XML.zip.

That behaviour might be fixed by some maximum recursion depth parameter. I hope that helps a little bit. If more investigation is necessary, I will be happy to assist.

  • 👍3
cowtowncoder commented
0roman commented

@cowtowncoder great to hear that, is a public issue fine for you?

I agree, although it might be relevant for the severity what the default settings are. According to the fuzz target (https://github.com/google/oss-fuzz/blob/master/projects/xstream/XmlFuzzer.java) the vulnerability in xstream was just triggered with some default xstream settings.

cowtowncoder commented

@0roman yes, public issue is fine.

pjfanning commented

@0roman I added a PR (#159)

  • 👍1
cowtowncoder commented

Aside from patch, can anybody figure out which CVE(s) this specifically addresses? All 6? One of them?
I'd want this issue (or another one(s) if need be) to clearly indicate one(s) addressed.

@pjfanning thank you; I hope to check this ASAP.

pjfanning commented

@cowtowncoder all 6 have exactly the same unhelpful description - I think we should appeal and get all but one closed and use the one remaining one used for #159 change

marcelstoer commented

I think we should appeal and get all but one closed

Yep, we tried, didn't happen: x-stream/xstream#304 (comment).

cowtowncoder commented

Alas! It's a shame that there's probably some incentives to file multiple CVEs, take credit, even if the root causes are the same. I can also understand how it may be difficult to tell from symptoms / reproductions how many distinct issues there are. Still, in this case vagueness should be considered in consolidating them. But it is what it is I guess.

cowtowncoder commented

Whops. I filed #160 as I forgot there was this one already, so release notes refer to that.
Will add a back-reference from there to here.