New OSS-Fuzz Findings in xstream

[henryrneh]

Dear xstream maintainers,

Multiple bugs(Stackoverflows) were found during fuzzing by Jazzer in xstream. We would like to provide you with access to the bugs at Google OSS-Fuzz before they get publicly disclosed.

What do we need from you?

We need an email address that is associated with a Google Account as per Accept new projects. In the past we have already contacted you during the onboarding of your project, but the request was rejected or no email was shared with us.

What do you get by sharing your email address?

When a bug is found, you will receive an email that will provide you with access to ClusterFuzz, crash reports, code coverage reports and fuzzer statistics. Each finding will have a crashing input that you can use to easily reproduce the bug.

Attention: All bug details will be made public automatically after the deadline of 90 days has exceeded or after the fix is released. For projects without maintainers we will do our best to support the disclosure process. Depending on our resources we will try to create an issues for every bug in your public issues tracker. In addition, we will request CVEs for security related vulnerabilities.

Please let me know if you have any questions regarding fuzzing or the OSS-Fuzz integration.

Thank you for your reading and hope to hear from you soon!

[henryrneh]

Dear xstream maintainers,

this is a friendly reminder, are you guys interested in onboarding to the OSS-Fuzz platform?

If we can not get maintainers from your project we will do our best to disclose issues to the community, and also request CVEs for security related vulnerabilities.

Thank you and hope to hear from you soon!

[henryrneh]

OSS-Fuzz has found this stackoverflow issue which has already been fixed due to fix by sonarqube. I think there is a potential security risk depending on the context of the usage of this project. A stackoverflow could lead to a denial of service of a component. We think the community should be notified. Do you plan to assign CVEs for the problems?

Detailed Information can be found here:

https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=49858

Please let me know if you have any questions regarding fuzzing or the OSS-Fuzz integration.

[joehni]

"Dear XStream maintainers" addresses in fact me alone and my spare time is currently very limited. Especially the next two weeks I am completely offline...

[henryrneh]

No problems! We will take over for most of the part then, in the future we will ask questions related to if the bugs found by OSS-Fuzz is really security related or not, that will help us to contribute to the community.

And thank you for your reply!

[joehni]

Hi, one question here:

OSS-Fuzz has found this stackoverflow issue which has already been fixed due to fix by sonarqube.

?!? When I look at the report, it claims that a security issue has been fixed by a commit that introduced the diamond operator as syntactical sugar?

Regards, Jörg

[henryrneh]

Hello @joehni,

We did not look into the commit details of this issue, we get our conclusion based on the fixed revision range of commits on Github. I think the issue is opened now so the above link should work, otherwise if you need stacktraces or crashing input please let me know, thanks!

Best regards, Henry

[tomabai]

Hi guys, I don't understand, is the issue here is directly in xtream project, or it comes from woodstox which is a dependency of this project? It seems that the vulnerable class comes from woodstox: https://github.com/FasterXML/woodstox/blob/master/src/main/java/com/ctc/wstx/dtd/FullDTDReader.java#L3050

Regards, Tom

[marcelstoer]

@henryrneh I am sure you and the organization you represent mean well. However, to me this issue is yet another example of misguided automated tools. A considerable amount of my time at $work is spent fighting such nonsense these days. As soon as something is in the CVE database, tools like the OWASP Dependency Check pick it up, build pipelines around the world start failing and all hell breaks loose.

There are currently 6 duplicate CVEs pointing here - all wrong.

CVE	OSS-Fuzz "bug"	Vulnerable class	OSS-Fuzz Security Severity
CVE-2022-40151	47367	n/a, permission denied	n/a
CVE-2022-40152	47434	n/a, permission denied	n/a
CVE-2022-40153	49858	com.ctc.wstx.dtd.FullDTDReader	low
CVE-2022-40154	50393	com.ctc.wstx.dtd.FullDTDReader	low
CVE-2022-40155	50428	com.ctc.wstx.dtd.FullDTDReader	low
CVE-2022-40156	50841	com.ctc.wstx.dtd.FullDTDReader	low

• FullDTDReader is NOT from this project but from https://github.com/FasterXML/woodstox.
• All OSS-Fuzz bugs appear to be duplicates of one another.
• All CVEs have a CVSS score of "7.5 HIGH". Yet, the OSS-Fuzz score is "low" for all.

Whoever create the CVEs should

• have done their homework beforehand
• reach out to NIST to have the CVEs revoked or updated
• create an issue with FasterXML/woodstox

[henryrneh]

Hello @marcelstoer @tomabai thanks for your feedback.

Just for clarification, the vulnerabilities are triggered with xstream.fromXML(Malicious_Input).

For the CVE-2022-40151, according to the stacktrace it seeems like a problem within xstream, I will include the full stacktrace here. 47367.txt

From the CVE-2022-40152 to CVE-2022-40156, they are not duplicates, if you look into the stacktrace in details you can see that they are triggered differently, but the root cause may be the same. 47434.txt

We will report the woodstox issues to woodstox. Since our ressources are also limited, we are not able investigate every issue in detail. If some well established project committer of xtream is interested in supporting the bug disclosure and issue handling, feel free to reach to us. Each finding can also be discussed before it is disclosed.

Since xstream is using woodstox, xtream users may be affected if an older version of xtream is used that was released with a vulnerable version of woodstox, so we still consider them to be valid CVEs.

[marcelstoer]

the vulnerabilities are triggered with xstream.fromXML(Malicious_Input).

That is not relevant. What if you find 100 projects out in the wild that invoke vulnerableLibrary.vulnerableMethod()? The sane thing to is to report this once to the vulnerableLibrary project and not to the 100 projects that invoke said library.

Since our ressources are also limited, we are not able investigate every issue in detail.

Then don't report them to NIST. Bulk posting such issues to NIST will eventually degrade the reputation of their database and render it useless over time. As a security researcher you have a professional obligation IMO to make sure that your automated tools don't steal time from developers around the globe.

[henryrneh]

For the first one CVE-2022-40151 the vulnerable library is still xstream.

For the other five, you're right. We will request an update at the vulnerability database to point to woodstox.

Since the first one is still not fixed, feel free to reach to us to get access to the Fuzzing infrastructure.

[cowtowncoder]

Also PLEASE DO NOT tag Woodstox in CVEs until you actually verify this is something to do with Woodstox internals and not -- for example -- due to PARTICULAR CONFIGURATION used by another library (like XStream; not claiming it does anything but just as an example).

I was contacted by a user who was freaking out on 5 new CVEs labelled with Woodstox; none of which I was familiar with. This is not ok.

And just to make it clear, I am not blaming fellow OSS authors about doing anything wrong. It is definitely reasonably to point out where within call stack things happen. But I am frustrated about filing this like CVEs solely based on non-validated exceptions by fuzzers. It is not enough to simply see an exception and demand someone else to do actual investigation, in my opinion. There is need for collaboration.

[Davrosss]

Hey team,

I was looking through the comments in the X-Stream issue attached to the CVE: https://github.com/x-stream/xstream/issues/304#issuecomment-1253519104

A commenter (tomabai) mentioned it seems to be around this line of code: https://github.com/FasterXML/woodstox/blob/master/src/main/java/com/ctc/wstx/dtd/FullDTDReader.java#L3050

Is there any merit to the comment? Could this function be causing this issue?

P.S. I am in cyber security and this stuff drives me crazy also. Its conuterproductive and punishes developers for implementing DevSecOps which has real implications when it comes to blocking pipelines. Automation is compounding the issue.

[cowtowncoder]

Without any other context it is not possible to know what problem there might be; I don't see anything super obvious. (but then again, I wrote that code ~15 years ago or so).

That kind of comment ("hey it seems to come from this class") with no context or even content is counter-productive. Not even a hint of HOW it was problematic. But I guess there was one line in stack trace that pointed there or something?

[zfl926]

Hi team,

It seems that this CVEs are still in the database which also block our release. So I want to know is there any workaround to skip this issue ?

Thanks

[cowtowncoder]

Someone needs to file proper, per-CVE issues, outlining the actual problem. CVE descriptions are often not good on their own. If the underlying problem is elsewhere (like Woodstox), issues are needed there, and something on XStream side to reference those.

Work-around also requires understanding of the issue.

People should (IMO) stop just filing "Fix CVE-XXXX-YYY" content-free issues: these are not helpful. Of course it's whoever files CVE that absolutely should contact maintainers/owners with this information, not users. I am not sure why this is not done: CVE submission has the checkbox of "I have contacated authors". Maybe it can be left off, or maybe someone just lies and claims to have done that. Or sent email but never verified if anything came of it (did recipient even read it?).

[kadinwu]

Any update for this issue? this is false positive? Thanks!

[cowtowncoder]

@kadinwu My impression is that it is not being actively looked at.

If you are interested, feel free to dig in and figure out what this RFC is about. More information about actual details would be helpful for maintainers of relevant libraries. At this, for example, no issues having been filed against Woodstox. Similarly, information here is mostly "hey, here's OSS-Fuzz crash report" which is often not sufficient to understand issue (if any) without more work digging into root cause. So anyone wanting to help could go and do that investigation, without having to figure out if and how to address the problem: understanding the problem is the first step.

[pjfanning]

clusterfuzz-testcase-minimized-XmlFuzzer-4554788485857280.txt

This is the invalid XML that causes this issue in case anyone wants to try to debug and fix this.

Based on #262, many users should probably consider switching to an alternative API/lib - eg XMLInputFactory (StAX parser) that is in the Java runtime - Woodstox is an implementation of this API (but Java runtimes have their own reference impl too).

[cowtowncoder]

Thank you for the link @pjfanning. That reproduction is humongous. That's one downside of fuzzing I guess, it generates whatever triggers necessary failure case. For test case it'd probably be good to figure out a cleaner repro but maybe that is easier by starting this specific case.

[darakian]

Hey all, joining this thread by way of https://github.com/github/advisory-database/pull/764 and I'm trying to make sense of it for advisory purposes. @henryrneh have you filed to update the CVEs? If so is there anything public one can follow on that? Do you have complete affected version ranges? Do you plan to aid in fixing the issues? Any timelines for that if so?

[cowtowncoder]

There is now an issue and possible PR for Woodstox. So depending on time availability, we might have a fix and then release within next week or so.

With all of this I am not sure if XStream is even affected -- doesn't it use defaults that disable DTD handling? Or is this not practical due to backwards-compatibility concerns? -- but it should be possible to resolve these duplicate CVEs relatively soon.

[henryrneh]

Dear xstream maintainers and users,

We have provided detailed information regarding the CVE-2022-40151, please have a look in https://github.com/x-stream/xstream/issues/314.

Regarding CVE-2022-40152, CVE-2022-40153, CVE-2022-40154, CVE-2022-40155, CVE-2022-40156, they are addressed in woodstox in https://github.com/FasterXML/woodstox/issues/157 and they are already fixed in https://github.com/FasterXML/woodstox/pull/159. The update of the 5 CVEs is in progress, and the duplicates will be deleted.

[cowtowncoder]

Ok; on Woodstox side issue is

• https://github.com/FasterXML/woodstox/issues/160

and is fixed for releases now going out to Maven Central, Woodstox-core

• 6.4.0 (main version)
• 5.4.0 (backported fix)

Once release is out I'll modify description of issue and release notes to mention main CVE.

[darakian]

I've updated the 5 CVEs in the GitHub database to reference com.fasterxml.woodstox:woodstox-core rather than com.thoughtworks.xstream:xstream.

[pjfanning]

@darakian could you add the fix versions (fixed in v5.4.0 and v6.4.0)? And would it be possible to get the 5 descriptions updated? For example, it should be mentioned that the issue affects DTD parsing only - because many users disable DTD support (this is strongly recommended to avoid XXE risks).

[darakian]

@pjfanning the fix versions should be on there. As for the description; yes I've gone ahead and added some language about DTD parsing.

[cowtowncoder]

@henryrneh @darakian Just to make sure:

1. How many CVEs will remain (that is, are some being closed as duplicates)?
2. Which CVEs will remain and be addressed by Woodstox fix? I am hoping to indicate specific CVE ids in issue and release notes

[henryrneh]

We have requested that one will remain for woodstox (CVE-2022-40152), and that the duplicates (CVE-2022-40153, CVE-2022-40154, CVE-2022-40155 and CVE-2022-40156) will be deleted. Those using Woodstox in Xstream have DTD support enabled by default, at least that's the way how the vulnerability in woodstox was found, see Xstream fuzz target.

One will remain for Xstream (CVE-2022-40151) which is still open, see https://github.com/x-stream/xstream/issues/314.

[darakian]

How many CVEs will remain (that is, are some being closed as duplicates)?

@cowtowncoder I hadn't planned to remove any of the CVEs, but if @henryrneh plans to revoke them then we will reflect that revocation.

Which CVEs will remain and be addressed by Woodstox fix?

In the github database at least I've tagged the following CVEs with the woodstox package. Happy to correct if I'm wrong or to improve the descriptions if you have suggestions 😃 CVE-2022-40151 CVE-2022-40152 CVE-2022-40153 CVE-2022-40154 CVE-2022-40155 CVE-2022-40156

@henryrneh I've swapped 40151 over to woodstox based on https://github.com/FasterXML/woodstox/issues/160. Was that incorrect?