In November of 2015, Foxglove Security posted about CVE-2015-4852 in the Java library “commons-collections”. It was discovered that untrusted or malformed data could be used to abuse application logic and for arbitrary code execution when deserialized after transportation. Serialization is used in Java to convert objects into byte streams for transmission. These byte streams then stream data packets across networks and the internet. When the packets are received at their destination, they are deserialized and reassembled.
Organizations tend to optimize performance of their applications by removing the layers of protection that check and validate trust of traffic as this additional security adds extra load and consumes additional resources. This trust becomes vulnerable if packets have been tampered with before arriving at their destination. When this tampered data is reformed into Java objects for example, it can allow for arbitrary code execution and/or other malicious actions. The unverified deserialized code is viewed as trusted valid data. In addition to Java, C, C++, Python, Ruby, and others are vulnerable to this type of trust issue.
Data integrity is compromised by not taking advantage of deserialization-serialization features and not using protection accessor functions for Java objects. Raw output streams of objects can compromise your confidentiality when not protecting Java objects from default overloaded functions. If you do not use the transient modifier (a modifier that causes the Java serializer to ignore a field when deserializing an object) you may also run into confidentiality issues. On a much more severe level, this vulnerability can lead to remote access of applications that are internal to your organization as well as public facing. In addition to being able to steal and corrupt data, an attacker could use the server itself to launch attacks and maintain a point of entry into your network.
This vulnerability affects a lot of Java applications due to the prolific use of the Apache commons-collection libraries. If you don’t use generic types, you are not vulnerable. An attacker can’t inject a malicious class because you explicitly define all of your Java objects beforehand. Versions 3.2.2 and 4.1 of the commons-collections library have addressed this issue and should be upgraded from previous versions (https://issues.apache.org/jira/browse/COLLECTIONS-580). Mitigation depends on two factors: the level of cryptography used and the level of application layer security implemented. Cryptography, while useful and recommended, is only going to protect you on the client side. Ensure your application is secure by using transient fields that result when any attempt to serialize then deserialize a class is made where non-transient data should be present.
When traffic is traveling from point A to point B, there needs to be certain levels of authentication and verification in place to ensure the authenticity of the transmitter and secure the transmission for the receiver. SSH and SSL/TLS are the recommended solutions for securing your traffic. This vulnerability should be taken seriously and looked into immediately if you suspect that you have any endpoints that are sending/receiving data and the source and data are not being validated.
In conclusion, anytime an application deserializes untrusted data, you run the risk of a high-level severity attack on your systems. It’s important to secure your application at both the application layer and transport layer using the tools available to the open source community. Other alternatives to object serialization, such as json-io or XML marshaling, should also be considered.