Warning over Java libraries and deserialization security weaknesses
(2022/08/22)
- Reference: 1661198415
- News link: https://www.theregister.co.uk/2022/08/22/java_library_flaws/
- Source link:
Boffins at universities in France, Germany, Luxembourg, and Sweden took a deep dive into known Java deserialization vulnerabilities, and have now resurfaced with their findings. In short, they've drawn attention to the ways in which libraries can accidentally introduce serious security flaws.
Serialization is used to convert a data object in memory into a series of bytes for storage or transmission. [1]Deserialization reverses that process by turning a data stream back into an object in memory.
In Java, this is implemented using the java.io.Serializable interface. But deserialization isn't necessarily safe because reconstructing the object from its byte stream doesn't involve the constructor – the blueprint code that initially builds the object to have whatever functions and methods it should have. If the constructor had any validation checks, those don't get run. Thus it's possible for deserialization to create objects that are invalid or have altered data.
[2]
Java deserialization bugs can be fairly serious.
[3]
[4]
For example, [5]Log4Shell , the remote code execution flaw affecting the Apache Log4j logging library was made possible by Java deserialization. In November 2016, [6]a ransomware attack compromised more than two thousand computers run by the San Francisco Municipal Transportation Agency (SFMTA) [7]via an Apache Commons Collections Deserialization Vulnerability.
Also, the entry point for the 2017 Equifax hack that resulted in the theft of personal data from 147.7 million Americans came from a Java deserialization [8]flaw in Apache Struts. And last July, there was an Atlassian [9]Jira vulnerability in which an attacker capable of connecting to an Ehcache RMI network service "could execute arbitrary code of their choice in Jira through deserialization due to a missing authentication vulnerability."
[10]
In [11]a paper titled, "An In-depth Study of Java Deserialization Remote-Code Execution Exploits and Vulnerabilities," computer scientists Imen Sayar (University of Toulouse), Alexandre Bartel (Umeå University), Eric Bodden (Paderborn University), and Yves Le Traon (University of Luxembourg) describe how they examined software libraries targeted by [12]19 publicly known Java deserialization RCE exploits to understand how gadgets – exploitable code constructs – get introduced into Java libraries and how attempts to get rid of these gadgets sometimes fail.
While serialization and deserialization are useful, the authors observe, this process introduces risk if the deserialized data comes from an untrusted source. "Indeed, an attacker could craft a byte stream that, when deserialized on the remote host, could control the execution flow of the Java code by chaining sequences of Java code called gadgets," they explain.
[13]AWS's Log4j patches blew holes in its own security
[14]Microsoft's huge Patch Tuesday includes fix for bug under attack
[15]Bad things come in threes: Apache reveals another Log4J bug
The term gadget has a few specific meanings in the world of vulnerability exploitation. For their paper, the authors use the word to refer to a potentially exploitable Java method accessible to the attacker. A library may contain gadgets that may be chainable, so they can operate in a sequence.
Taking advantage of a deserialization vulnerability can involve a complicated attack chain or it may be as simple as [16]making a GET request over a network.
Our main conclusion is that the modification of one innocent-looking detail in a class – such as making it public – can already introduce a gadget
The researchers looked at 19 exploits for vulnerabilities in [17]14 libraries (some with multiple versions): beanshell , clojure , commons-beanutils , commons-collections , groovy , rome , js-rhino , spring-beans , spring-core , spring-aop , click-nodeps , javax.servlet , vaadin-server , and vaadin-shared .
"When analyzing the 19 RCE exploits, we have identified several ways to introduce a gadget in a library: adding classes, methods, and interfaces, or changing the signature of methods," the paper reads. "Our main conclusion is that the modification of one innocent-looking detail in a class – such as making it public – can already introduce a gadget."
Given that gadgets are necessary to create a deserialization exploit, code modification that inserts new gadgets is clearly not ideal.
[18]
Of the libraries and their variants tested, 14 have been patched to remove potential gadgets. This can be done in various ways, such as removing java.io.Serializable from the list of interfaces in a vulnerable class, removing the vulnerable class in its entirety, or introducing a safety check, among other techniques.
Six of the libraries evaluated ( commons-beanutils1.9.4 , rome1.0 , spring-beans-3.0.0.RELEASE , click-nodeps-2.3.0-RC1 , javax-servlet-api-4.0.1 , and vaadin-shared-7.4.0.beta1 ) are listed as not patched. So if your applications include any of them, you may want to consider how to address that. Waiting for a fix, however, may not be the best option.
"When studying patches of such libraries, we observed that the time used to remove gadgets varies between several months and almost 12 years, with an average of almost six years," the researchers conclude. "It thus appears that deserialization vulnerabilities do not yet get the attention of practitioners that they should actually deserve." ®
Get our [19]Tech Resources
[1] https://cheatsheetseries.owasp.org/cheatsheets/Deserialization_Cheat_Sheet.html
[2] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_security/front&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=2&c=2YwP8dgXtlgD7TZvklq-9@gAAAMg&t=ct%3Dns%26unitnum%3D2%26raptor%3Dcondor%26pos%3Dtop%26test%3D0
[3] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_security/front&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=4&c=44YwP8dgXtlgD7TZvklq-9@gAAAMg&t=ct%3Dns%26unitnum%3D4%26raptor%3Dfalcon%26pos%3Dmid%26test%3D0
[4] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_security/front&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=3&c=33YwP8dgXtlgD7TZvklq-9@gAAAMg&t=ct%3Dns%26unitnum%3D3%26raptor%3Deagle%26pos%3Dmid%26test%3D0
[5] https://www.theregister.com/2021/12/13/log4j_rce_latest/
[6] https://www.theregister.com/2016/11/27/san_francisco_muni_ransomware/
[7] https://blogs.apache.org/foundation/entry/apache_commons_statement_to_widespread
[8] https://www.theregister.com/2017/09/05/apache_struts_vuln/
[9] https://confluence.atlassian.com/adminjiraserver/jira-data-center-and-jira-service-management-data-center-security-advisory-2021-07-21-1063571388.html
[10] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_security/front&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=4&c=44YwP8dgXtlgD7TZvklq-9@gAAAMg&t=ct%3Dns%26unitnum%3D4%26raptor%3Dfalcon%26pos%3Dmid%26test%3D0
[11] https://arxiv.org/abs/2208.08173
[12] https://github.com/frohoff/ysoserial
[13] https://www.theregister.com/2022/04/20/aws_log4j_patches/
[14] https://www.theregister.com/2022/04/13/microsoft_patch_tuesday/
[15] https://www.theregister.com/2021/12/19/log4j_new_flaw_cve_2021_45105/
[16] https://portswigger.net/research/pre-auth-rce-in-forgerock-openam-cve-2021-35464
[17] https://github.com/software-engineering-and-security/java-deserialization-rce
[18] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_security/front&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=3&c=33YwP8dgXtlgD7TZvklq-9@gAAAMg&t=ct%3Dns%26unitnum%3D3%26raptor%3Deagle%26pos%3Dmid%26test%3D0
[19] https://whitepapers.theregister.com/
Serialization is used to convert a data object in memory into a series of bytes for storage or transmission. [1]Deserialization reverses that process by turning a data stream back into an object in memory.
In Java, this is implemented using the java.io.Serializable interface. But deserialization isn't necessarily safe because reconstructing the object from its byte stream doesn't involve the constructor – the blueprint code that initially builds the object to have whatever functions and methods it should have. If the constructor had any validation checks, those don't get run. Thus it's possible for deserialization to create objects that are invalid or have altered data.
[2]
Java deserialization bugs can be fairly serious.
[3]
[4]
For example, [5]Log4Shell , the remote code execution flaw affecting the Apache Log4j logging library was made possible by Java deserialization. In November 2016, [6]a ransomware attack compromised more than two thousand computers run by the San Francisco Municipal Transportation Agency (SFMTA) [7]via an Apache Commons Collections Deserialization Vulnerability.
Also, the entry point for the 2017 Equifax hack that resulted in the theft of personal data from 147.7 million Americans came from a Java deserialization [8]flaw in Apache Struts. And last July, there was an Atlassian [9]Jira vulnerability in which an attacker capable of connecting to an Ehcache RMI network service "could execute arbitrary code of their choice in Jira through deserialization due to a missing authentication vulnerability."
[10]
In [11]a paper titled, "An In-depth Study of Java Deserialization Remote-Code Execution Exploits and Vulnerabilities," computer scientists Imen Sayar (University of Toulouse), Alexandre Bartel (Umeå University), Eric Bodden (Paderborn University), and Yves Le Traon (University of Luxembourg) describe how they examined software libraries targeted by [12]19 publicly known Java deserialization RCE exploits to understand how gadgets – exploitable code constructs – get introduced into Java libraries and how attempts to get rid of these gadgets sometimes fail.
While serialization and deserialization are useful, the authors observe, this process introduces risk if the deserialized data comes from an untrusted source. "Indeed, an attacker could craft a byte stream that, when deserialized on the remote host, could control the execution flow of the Java code by chaining sequences of Java code called gadgets," they explain.
[13]AWS's Log4j patches blew holes in its own security
[14]Microsoft's huge Patch Tuesday includes fix for bug under attack
[15]Bad things come in threes: Apache reveals another Log4J bug
The term gadget has a few specific meanings in the world of vulnerability exploitation. For their paper, the authors use the word to refer to a potentially exploitable Java method accessible to the attacker. A library may contain gadgets that may be chainable, so they can operate in a sequence.
Taking advantage of a deserialization vulnerability can involve a complicated attack chain or it may be as simple as [16]making a GET request over a network.
Our main conclusion is that the modification of one innocent-looking detail in a class – such as making it public – can already introduce a gadget
The researchers looked at 19 exploits for vulnerabilities in [17]14 libraries (some with multiple versions): beanshell , clojure , commons-beanutils , commons-collections , groovy , rome , js-rhino , spring-beans , spring-core , spring-aop , click-nodeps , javax.servlet , vaadin-server , and vaadin-shared .
"When analyzing the 19 RCE exploits, we have identified several ways to introduce a gadget in a library: adding classes, methods, and interfaces, or changing the signature of methods," the paper reads. "Our main conclusion is that the modification of one innocent-looking detail in a class – such as making it public – can already introduce a gadget."
Given that gadgets are necessary to create a deserialization exploit, code modification that inserts new gadgets is clearly not ideal.
[18]
Of the libraries and their variants tested, 14 have been patched to remove potential gadgets. This can be done in various ways, such as removing java.io.Serializable from the list of interfaces in a vulnerable class, removing the vulnerable class in its entirety, or introducing a safety check, among other techniques.
Six of the libraries evaluated ( commons-beanutils1.9.4 , rome1.0 , spring-beans-3.0.0.RELEASE , click-nodeps-2.3.0-RC1 , javax-servlet-api-4.0.1 , and vaadin-shared-7.4.0.beta1 ) are listed as not patched. So if your applications include any of them, you may want to consider how to address that. Waiting for a fix, however, may not be the best option.
"When studying patches of such libraries, we observed that the time used to remove gadgets varies between several months and almost 12 years, with an average of almost six years," the researchers conclude. "It thus appears that deserialization vulnerabilities do not yet get the attention of practitioners that they should actually deserve." ®
Get our [19]Tech Resources
[1] https://cheatsheetseries.owasp.org/cheatsheets/Deserialization_Cheat_Sheet.html
[2] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_security/front&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=2&c=2YwP8dgXtlgD7TZvklq-9@gAAAMg&t=ct%3Dns%26unitnum%3D2%26raptor%3Dcondor%26pos%3Dtop%26test%3D0
[3] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_security/front&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=4&c=44YwP8dgXtlgD7TZvklq-9@gAAAMg&t=ct%3Dns%26unitnum%3D4%26raptor%3Dfalcon%26pos%3Dmid%26test%3D0
[4] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_security/front&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=3&c=33YwP8dgXtlgD7TZvklq-9@gAAAMg&t=ct%3Dns%26unitnum%3D3%26raptor%3Deagle%26pos%3Dmid%26test%3D0
[5] https://www.theregister.com/2021/12/13/log4j_rce_latest/
[6] https://www.theregister.com/2016/11/27/san_francisco_muni_ransomware/
[7] https://blogs.apache.org/foundation/entry/apache_commons_statement_to_widespread
[8] https://www.theregister.com/2017/09/05/apache_struts_vuln/
[9] https://confluence.atlassian.com/adminjiraserver/jira-data-center-and-jira-service-management-data-center-security-advisory-2021-07-21-1063571388.html
[10] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_security/front&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=4&c=44YwP8dgXtlgD7TZvklq-9@gAAAMg&t=ct%3Dns%26unitnum%3D4%26raptor%3Dfalcon%26pos%3Dmid%26test%3D0
[11] https://arxiv.org/abs/2208.08173
[12] https://github.com/frohoff/ysoserial
[13] https://www.theregister.com/2022/04/20/aws_log4j_patches/
[14] https://www.theregister.com/2022/04/13/microsoft_patch_tuesday/
[15] https://www.theregister.com/2021/12/19/log4j_new_flaw_cve_2021_45105/
[16] https://portswigger.net/research/pre-auth-rce-in-forgerock-openam-cve-2021-35464
[17] https://github.com/software-engineering-and-security/java-deserialization-rce
[18] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_security/front&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=3&c=33YwP8dgXtlgD7TZvklq-9@gAAAMg&t=ct%3Dns%26unitnum%3D3%26raptor%3Deagle%26pos%3Dmid%26test%3D0
[19] https://whitepapers.theregister.com/
Sign of the Times
HildyJ
We live in a time where many programmers are never taught the lessons of the past - like always verify your input data.
Furthermore, too many programmers are unwilling (due to personal preferences or management directive) to spend time and money on security - hence the average of 6 years to remove gadgets.
Given this, the boffins' finding are alarming but not surprising.
No intended as a slap
Anonymous Coward
But the basic premise of Java was to make a language for programmers you couldn't trust based on a java VM that was built by programmers you could. This got turned inside out, as the JVM is bug ridden trash, and even a good programmer has a hard time coding around all the glaring issues.
You gave up pointers for this mess, but as it still let's any newbie call "public static shoot(my.foot)" what's the point? It seems like Java gave up on the idea of user safe or programmer safe code, and is just fighting against change at this point. If it allows easy and unchecked security problems in deserialization, why block other useful operations based on the idea that their use is similarly risky? Inertia seems the clear choice. And as the community bleeds mind share to other platforms, it seems like that inertia is becoming an existential threat to the community.
NSS
I’m a hobbyist Java programmer & I’ve been playing with Java for 10-15 years. Even I know that standard Java serialization is dangerous.
If full-time Java programmers are using standard Java serialization, they really need to go back to school.
This problem of object serialization being unsafe is not unique to Java. Other languages offer similar features and all give the same dire warnings: Don’t use it if you can’t trust the input.
What’s one of the standard security warnings for programmers? Never trust user supplied input.