Dark Reading is part of the Informa Tech Division of Informa PLC

This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them.Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.

Vulnerabilities / Threats

03:40 PM
Derek Weeks
Derek Weeks
Connect Directly
E-Mail vvv

Java Deserialization: Running Faster Than a Bear

Software components that were once good can sour instantly when new vulnerabilities are discovered within them. When that happens, the bears are coming, and you have to respond quickly.

Two men are walking through a forest. Suddenly, they see a bear off in the distance, running toward them. Adrenaline pumping, they start running away. But then one of them stops, takes some running shoes from his bag and starts putting them on.

“Frank, what are you doing?” says the other man. “Do you think you will run faster than the bear with those?”

“I don’t need to run faster than the bear,” Frank replies. “I just have to run faster than you.”

This scenario repeats itself every time a new security vulnerability is discovered in a widely used open source component. Imagine the bear as your adversary. Rushing to attack when easy prey is present. Your response time is critical.

Sneakers on. Go!

Racing to Answer Four Questions

Late last year, security researchers from FoxGlove Security announced a critical vulnerability in applications using Apache Commons Collection. The component is so widely used in Java development, countless organizations were impacted. The FoxGlove report revealed vulnerable instances of the component in open source applications like WebLogic, WebSphere, JBoss and Jenkins. Simultaneously, Java development and IT operations teams around the globe raced to discover four things:

  1. Did we use the Commons Collection component?
  2. If yes, which applications are using it?
  3. Are we vulnerable?
  4. If yes, how soon can we fix the flawed component?

As soon as the vulnerabilities were announced, the bears were charging to their doorstep. Response times were vital.

Lessons learned at PayPal

Earlier this year, PayPal shared its own experience with the deserialization vulnerability. Their engineering team blogged, “we began forking a few work-streams to assess the impact to our application infrastructure … As it turned out, this bug was found in one of our apps that was not on our core Java frameworks. Once we validated the bug, the product development and security teams quickly moved to patch the application in a couple of days.”

Knowing they were not alone in the development community racing to fix a vulnerable application, PayPal shared several lessons learned, like:

  • Where do you start?
  • Let real-world risk drive your priorities.
  • You need to make sure that the critical risk assets get the first attention.

When it comes to eliminating known vulnerabilities in critical applications, we can see from PayPal that speed, focus and community engagement all play a critical role in staying ahead of the bear.

Houston, we have a problem

When I first read about the vulnerability deserialization issue, I reached out to our Sonatype security team. They were already on the case to assess any impact to our own products (luckily, we were not impacted). My next step was reaching out to my friends at CloudBees (creators of Jenkins). Thankfully, their development team was already on top of it and released a newer version within just a few days of the alert.

But, the story does not end there. Researchers at Sonatype have identified deserialization issues in over 30,000 unique components stored in our company’s Central Repository.

The issue of vulnerabilities is far reaching. When we started looking at the download patterns of open source components from the Central Repository, we noticed the download consumption patterns of the known vulnerable versions of popular components were undistinguished from the good ones. People are using known vulnerable components for years and years after safer versions of those same components have been announced and released. In many cases, the open source projects themselves are not aware of vulnerabilities they are harboring.

 Why is this? It is not because people intend to build flawed software. It’s most likely, because they were not aware of the problem.  This is because:

  1. Security, quality and speed are critical to modern software (business) success.
  2. The world’s best software starts with the world’s best components.

Why components age like milk

We also realize that components sometimes age like milk. Components that were once good can sour instantly when new vulnerabilities are discovered within them. When that happens, the race is on. The bears are coming, and you have to respond.

[Read more about vulnerability management from Derek Weeks in 5 Steps to Improve Your Software Supply Chain Security.]

For some, the pace of their response resembles walking from the attacking bear. They have no idea what components have been consumed over the years across their software development practices. No records are kept. When a new vulnerability is announced (assuming they hear about it), the hunt reveals a manual, step-by-step analysis.

In one specific instance, a global banking entity told me that it took four people two months to detect if they were using vulnerable versions of Commons Collection across their application portfolio. (They had no running shoes.)

For others, it is a sprint at world-record pace. Organizations like Capital One, Intuit and FedEx have full visibility to the software supply chain that feeds components into their development organization. They know what components have been used and where. When new vulnerabilities are announced, they are automatically alerted to the use and location of that component.  

But responding at record pace is not an anomaly. You have to work at it. Global manufacturing giants like Toyota, Gilead Sciences, Apple and Lockheed have figured out how to run production lines at a ludicrous velocity while maintaining extremely low defect rates by continuously managing their supply chains. Knowing the bears won’t relent, it is time and it is possible for those managing software supply chains to do the same.

Gain insight into the latest threats and emerging best practices for managing them. Attend the Security Track at Interop Las Vegas, May 2-6. Register now!

Derek Weeks is passionate about applying proven supply chain management principles to improve efficiencies, reduce security risks, and sustain long-lasting competitive advantages. He is a distinguished international speaker and lectures regularly on modern software ... View Full Bio

Recommended Reading:

Comment  | 
Print  | 
More Insights
Newest First  |  Oldest First  |  Threaded View
User Rank: Author
4/15/2016 | 12:41:17 PM
All you wanted to know about deserialization and more
There is another great post on SlideShare describing deserialization issues, including how to find them, what to look for, tricks, how to exploit them, and the history of deserialization vulnerabilities: http://www.slideshare.net/codewhitesec/java-deserialization-vulnerabilities-the-forgotten-bug-class

User Rank: Author
4/15/2016 | 12:38:10 PM
Identifying components subject to this vulnerability
This blog post by Brian Fox helps describe more about the issues with open source components that are subject to deserialization vulnerabilities.  Well worth reading: http://www.sonatype.org/nexus/2015/11/13/did-you-wake-up-to-an-alert-about-the-java-deserialization-vulnerability/
User Rank: Author
4/14/2016 | 8:57:31 PM
Bad strategy?
The fundamental problem here is deserializing untrusted data, not sour components. There are probably an infinite number of gadgets (like the Commons Collection library mentioned) that can be used, so the component strategy is busted. Better solutions use instrumentation like Contrast-rO0 and other free tools.
7 Old IT Things Every New InfoSec Pro Should Know
Joan Goodchild, Staff Editor,  4/20/2021
Cloud-Native Businesses Struggle With Security
Robert Lemos, Contributing Writer,  5/6/2021
Defending Against Web Scraping Attacks
Rob Simon, Principal Security Consultant at TrustedSec,  5/7/2021
Register for Dark Reading Newsletters
White Papers
Current Issue
2021 Top Enterprise IT Trends
We've identified the key trends that are poised to impact the IT landscape in 2021. Find out why they're important and how they will affect you today!
Flash Poll
How Enterprises are Developing Secure Applications
How Enterprises are Developing Secure Applications
Recent breaches of third-party apps are driving many organizations to think harder about the security of their off-the-shelf software as they continue to move left in secure software development practices.
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
PUBLISHED: 2021-05-15
A XSS Vulnerability in /uploads/dede/action_search.php in DedeCMS V5.7 SP2 allows an authenticated user to execute remote arbitrary code via the keyword parameter.
PUBLISHED: 2021-05-15
DedeCMS V5.7 SP2 contains a CSRF vulnerability that allows a remote attacker to send a malicious request to to the web manager allowing remote code execution.
PUBLISHED: 2021-05-14
The Linux kernel before 5.11.14 has a use-after-free in cipso_v4_genopt in net/ipv4/cipso_ipv4.c because the CIPSO and CALIPSO refcounting for the DOI definitions is mishandled, aka CID-ad5d07f4a9cd. This leads to writing an arbitrary value.
PUBLISHED: 2021-05-14
In the Linux kernel before 5.12.4, net/bluetooth/hci_event.c has a use-after-free when destroying an hci_chan, aka CID-5c4c8c954409. This leads to writing an arbitrary value.
PUBLISHED: 2021-05-14
The block subsystem in the Linux kernel before 5.2 has a use-after-free that can lead to arbitrary code execution in the kernel context and privilege escalation, aka CID-c3e2219216c9. This is related to blk_mq_free_rqs and blk_cleanup_queue.