Hamartia Antidote
ELITE MEMBER
- Joined
- Nov 17, 2013
- Messages
- 35,188
- Reaction score
- 30
- Country
- Location
https://www.bleepingcomputer.com/ne...ion-support-the-source-of-most-security-bugs/
Oracle plans to drop support for data serialization/deserialization from the main body of the Java language, according to Mark Reinhold, chief architect of the Java platform group at Oracle.
Serialization is the process of taking a data object and converting it into a stream of bytes (binary format), so it can be transported across a network or saved inside a database, only to be deserialized later and used in its original form.
Serializing and deserializing data is not a problem by itself, or when the source of the data is known to be safe. These operations become dangerous when an app works with user-supplied data. For the rest of this article, we'll be referring to this latter case when we're going to refer to serialization and deserialization operations.
Because of its convenience, a large number of high-level programming languages support the feature but nowhere has it been more of a headache than in Java, where it's been at the heart of a constant stream of security flaws.
Reinhold: Serialization was a "horrible mistake"
Speaking to InfoWorld, Reinhold said in hindsight that adding serialization support to Java back in 1997 has been a "horrible mistake."
Reinhold says the Java team is currently working on dropping serialization support for good from the language's main body, but still provide developers with a plug-in system to support serialization operations if needed via a new framework.
There's no set date or Java version when Oracle plans to drop serilization, Reinhold said.
But until Oracle does this, companies and project leads that don't want a developer or a rogue module calling serialization/deserialization functions can prevent this via a "serialization filter" that was added in Java back in 2016, and which will block these operations altogether.
The serialization/deserialization security problem
Attacks via serialization/deserialization operations have been known for years, in a form or other, but they became everyone's problem in early 2015 when two researchers — Chris Frohoff and Gabriel Lawrence — found a deserialization flaw in the Apache Commons Collection, a very popular Java application.
Researchers from Foxglove Security expanded on the initial work in late 2015, showing how an attacker could use a deserialization flaw in Java applications where developers have incorrectly used the Apache Commons Collection library to handle deserialization operations.
Their experiments showed that an attacker could upload malicious data inside popular Java apps such as WebLogic, WebSphere, JBoss, Jenkins, and OpenNMS. This data would be serialized and stored in a database or in memory, but when the app would deserialize it, the app would also execute additional malicious code.
The flaw rocked the Java ecosystem in 2016, as it also affected 70 other Java libraries, and was even used to compromise PayPal's servers. Organizations such as Apache, Oracle, Cisco, Red Hat, Jenkins, VMWare, IBM, Intel, Adobe, HP, and SolarWinds , all issued security patches to fix their products.
That particular Java deserialization flaw was so dangerous that Google engineers banded together in their free time to repair open-source Java libraries and limit the flaw's reach, patching over 2,600 projects. Internally at Google, the flaw was referenced to as Mad Gadget, but the world referred to it as the Java Apocalypse.
While Java serialization/deserialization security issues were known for a long time, the 2015 Java Apocalypse served as a wake-up call for many companies, and the Java community as a whole, who started paying more attention to how they serialize and later deserialize data.
Serialization bugs have been a big problem for Java
Reinhold told InfoWorld that serialization issues could be very easily responsible for a third or even a half of all known Java flaws.
His assessment is most likely correct. For example, Oracle's January 2018 security updates fixed 237 vulnerabilities, of which 28.5% addressed unsafe deserialization operations.
The issue is also very widespread across companies. A ShiftLeft report revealed numerous serialization/deserialization flaws across a large number of SaaS vendor SDKs.
Just one Apache Struts (Java) deserialization bug from last year affected an estimated 65% of all Fortune 100 companies, showing how widespread the practice of serializing data is, and how one bug could bring down the security of the world's biggest companies.
But while Oracle is addressing the issue in Java, serialization also affects other programming environments like .NET, Ruby, and others, where the issue remains dormant.
Oracle plans to drop support for data serialization/deserialization from the main body of the Java language, according to Mark Reinhold, chief architect of the Java platform group at Oracle.
Serialization is the process of taking a data object and converting it into a stream of bytes (binary format), so it can be transported across a network or saved inside a database, only to be deserialized later and used in its original form.
Serializing and deserializing data is not a problem by itself, or when the source of the data is known to be safe. These operations become dangerous when an app works with user-supplied data. For the rest of this article, we'll be referring to this latter case when we're going to refer to serialization and deserialization operations.
Because of its convenience, a large number of high-level programming languages support the feature but nowhere has it been more of a headache than in Java, where it's been at the heart of a constant stream of security flaws.
Reinhold: Serialization was a "horrible mistake"
Speaking to InfoWorld, Reinhold said in hindsight that adding serialization support to Java back in 1997 has been a "horrible mistake."
Reinhold says the Java team is currently working on dropping serialization support for good from the language's main body, but still provide developers with a plug-in system to support serialization operations if needed via a new framework.
There's no set date or Java version when Oracle plans to drop serilization, Reinhold said.
But until Oracle does this, companies and project leads that don't want a developer or a rogue module calling serialization/deserialization functions can prevent this via a "serialization filter" that was added in Java back in 2016, and which will block these operations altogether.
The serialization/deserialization security problem
Attacks via serialization/deserialization operations have been known for years, in a form or other, but they became everyone's problem in early 2015 when two researchers — Chris Frohoff and Gabriel Lawrence — found a deserialization flaw in the Apache Commons Collection, a very popular Java application.
Researchers from Foxglove Security expanded on the initial work in late 2015, showing how an attacker could use a deserialization flaw in Java applications where developers have incorrectly used the Apache Commons Collection library to handle deserialization operations.
Their experiments showed that an attacker could upload malicious data inside popular Java apps such as WebLogic, WebSphere, JBoss, Jenkins, and OpenNMS. This data would be serialized and stored in a database or in memory, but when the app would deserialize it, the app would also execute additional malicious code.
The flaw rocked the Java ecosystem in 2016, as it also affected 70 other Java libraries, and was even used to compromise PayPal's servers. Organizations such as Apache, Oracle, Cisco, Red Hat, Jenkins, VMWare, IBM, Intel, Adobe, HP, and SolarWinds , all issued security patches to fix their products.
That particular Java deserialization flaw was so dangerous that Google engineers banded together in their free time to repair open-source Java libraries and limit the flaw's reach, patching over 2,600 projects. Internally at Google, the flaw was referenced to as Mad Gadget, but the world referred to it as the Java Apocalypse.
While Java serialization/deserialization security issues were known for a long time, the 2015 Java Apocalypse served as a wake-up call for many companies, and the Java community as a whole, who started paying more attention to how they serialize and later deserialize data.
Serialization bugs have been a big problem for Java
Reinhold told InfoWorld that serialization issues could be very easily responsible for a third or even a half of all known Java flaws.
His assessment is most likely correct. For example, Oracle's January 2018 security updates fixed 237 vulnerabilities, of which 28.5% addressed unsafe deserialization operations.
The issue is also very widespread across companies. A ShiftLeft report revealed numerous serialization/deserialization flaws across a large number of SaaS vendor SDKs.
Just one Apache Struts (Java) deserialization bug from last year affected an estimated 65% of all Fortune 100 companies, showing how widespread the practice of serializing data is, and how one bug could bring down the security of the world's biggest companies.
But while Oracle is addressing the issue in Java, serialization also affects other programming environments like .NET, Ruby, and others, where the issue remains dormant.
