Skip to content

Fix for Sonartype vulnerability CVE-2016-1000027 in Spring-web project #25104

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
gituserjava opened this issue May 19, 2020 · 7 comments
Closed
Labels
for: stackoverflow A question that's better suited to stackoverflow.com status: invalid An issue that we don't feel is valid

Comments

@gituserjava
Copy link

Do we have fix for Sonartype vulnerability CVE-2016-1000027 in Spring-web project in any of the latest version of Spring-web jar?

@spring-projects-issues spring-projects-issues added the status: waiting-for-triage An issue we've not yet triaged or decided on label May 19, 2020
@bclozel
Copy link
Member

bclozel commented May 19, 2020

I guess you're referring to this issue. In this case, it's not a security issue in the Spring Framework codebase, but rather well-known insecure setups that the reference documentation has been warning against for a very long time now.

So the underlying question here is: is your application is using Java deserialization using input from untrusted sources?

Thanks!

@bclozel bclozel closed this as completed May 19, 2020
@bclozel bclozel added for: stackoverflow A question that's better suited to stackoverflow.com status: invalid An issue that we don't feel is valid and removed status: waiting-for-triage An issue we've not yet triaged or decided on labels May 19, 2020
@rstoyanchev
Copy link
Contributor

See also answers under #24434.

@gituserjava
Copy link
Author

@bclozel , at the moment we are not using Java deserialization, but we see security vulnerability at build time and the builds are breaking and we are forced to not use this Jar. Security teams are not allowing such jars.

@bclozel
Copy link
Member

bclozel commented May 19, 2020

@gituserjava I'm sorry to hear that.

Java deserialization from untrusted sources is a broader problem that's not specific to Spring Framework. Any Java application (without any Spring dependency) can expose such vulnerabilities - this is more about best practices than an actual flaw in Spring Framework's codebase.

As you can see in #24434 there's nothing we can do here from a CVE perspective. Maybe you can get in touch with your security team or your security vulnerability tool vendor and work out this particular case?

@gituserjava
Copy link
Author

@bclozel , if we switch to Java 9 or above, will this be solved?

@bclozel
Copy link
Member

bclozel commented May 22, 2020

@gituserjava I don't think it will.
For further advice on application security, please reach out to your security team or vendor.
Thanks,

@artem-smotrakov
Copy link

FYI

Vulnerable applications can be detected using static code analysis.

If you use CodeQL, I've created two CodeQL queries that detect vulnerable service exporters:

This blog post describes the issue, shows an example of vulnerable code, and describes the queries.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
for: stackoverflow A question that's better suited to stackoverflow.com status: invalid An issue that we don't feel is valid
Projects
None yet
Development

No branches or pull requests

5 participants