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:
#304 (comment)

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.