Spring Core on JDK9 is vulnerable to remote code execution • Hacker News Board

Re: Spring Core on JDK9 is vulnerable to remote code execution

#71

Post by EdwardDiego » Sat, Apr 02, 2022, 12:57 PM UTC

mbfg wrote: post #63

EdwardDiego wrote: post #38

Earlier quoted context omitted.

Unfortunately you're wrong. While some companies haven't yet made the leap from 8 to 11, most have. You'll find that Java 8 support is being deprecated if not outright removed across the JVM ecosystem.

Can you point me to surveys to back up this claim? I interview lots of people from lots of companies, no one is using anything above java 8. Sure this evidence is anecdotal, but i've probably got evidence from around 150 companies.

Nothing I can share, sorry.

Re: Spring Core on JDK9 is vulnerable to remote code execution

#72

Post by alipitch » Wed, Apr 13, 2022, 5:39 AM UTC

Are there any data binding libraries (deserialization, marshaling, pickling libraries) that do not have the class of weaknesses as the two CVEs (CVE-2022-22965, CVE-2010-1622)?

My understanding is as follows.

- Spring uses WebDataBinder [0]. -> CVEs: CVE-2022-22965 (Spring4Shell), CVE-2010-1622 -> CVE Fixes: First deny-list approach (2010), then partial allow-list approach (2022)

- Struts uses OGNL. -> CVEs: CVE-2017-5638 (Equifax breach), and others -> CVE Fixes: deny-list approach (-2017-)

If there are any for Java, can they be used with Spring Boot (Spring Framework)? Maybe there are some for in another programming language?

[0] https://docs.spring.io/spring-framework/docs/current/javadoc... > Special DataBinder for data binding from web request parameters to JavaBean objects.

Re: Spring Core on JDK9 is vulnerable to remote code execution

#73

Post by alipitch » Wed, Apr 13, 2022, 6:13 AM UTC

alipitch wrote: post #72

Are there any data binding libraries (deserialization, marshaling, pickling libraries) that do not have the class of weaknesses as the two CVEs (CVE-2022-22965, CVE-2010-1622)? My understanding is as follows. - Spring uses WebDataBinder [0]. -> CVEs: CVE-2022-22965 (Spring4Shell), CVE-2010-1622 -> CVE Fixes: First deny-list approach (2010), then partial allow-list approach (2022) - Struts uses OGNL. -> CVEs: CVE-2017…

Also to understand the problem correctly, what is the class of weakness of the two CVEs (CVE-2022-22965, CVE-2010-1622)?

The following look like good candidates.

- CWE-915: Improperly Controlled Modification of Dynamically-Determined Object Attributes https://cwe.mitre.org/data/definitions/915.html> (Ruby on Rails Mass assignment bug)

- CWE-502: Deserialization of Untrusted Data https://cwe.mitre.org/data/definitions/502.html>

- CWE-470: Use of Externally-Controlled Input to Select Classes or Code ('Unsafe Reflection') https://cwe.mitre.org/data/definitions/470.html>

I think the one assigned (CWE-20:) is not a good approach to dealing with the "class" of weaknesses.

- CWE-20: Improper Input Validation https://cwe.mitre.org/data/definitions/20.html>

As long as you see this as a "CWE-20: Improper Input Validation" class problem, it seems like you try to fix this with a deny-list approach or a partial allow-list approach that needs additional fixing some time in the future.