DZone
Thanks for visiting DZone today,
Edit Profile
  • Manage Email Subscriptions
  • How to Post to DZone
  • Article Submission Guidelines
Sign Out View Profile
  • Post an Article
  • Manage My Drafts
Over 2 million developers have joined DZone.
Log In / Join
Refcards Trend Reports Events Over 2 million developers have joined DZone. Join Today! Thanks for visiting DZone today,
Edit Profile Manage Email Subscriptions Moderation Admin Console How to Post to DZone Article Submission Guidelines
View Profile
Sign Out
Refcards
Trend Reports
Events
Zones
Culture and Methodologies Agile Career Development Methodologies Team Management
Data Engineering AI/ML Big Data Data Databases IoT
Software Design and Architecture Cloud Architecture Containers Integration Microservices Performance Security
Coding Frameworks Java JavaScript Languages Tools
Testing, Deployment, and Maintenance Deployment DevOps and CI/CD Maintenance Monitoring and Observability Testing, Tools, and Frameworks
Culture and Methodologies
Agile Career Development Methodologies Team Management
Data Engineering
AI/ML Big Data Data Databases IoT
Software Design and Architecture
Cloud Architecture Containers Integration Microservices Performance Security
Coding
Frameworks Java JavaScript Languages Tools
Testing, Deployment, and Maintenance
Deployment DevOps and CI/CD Maintenance Monitoring and Observability Testing, Tools, and Frameworks
  1. DZone
  2. Coding
  3. Java
  4. Why Are Deserialization Vulnerabilities So Popular?

Why Are Deserialization Vulnerabilities So Popular?

Wondering why deserialization vulnerabilities are so popular? Click here to learn more about deserialization, why it happens, and CPU fixes.

Apostolos Giannakidis user avatar by
Apostolos Giannakidis
·
Nov. 05, 18 · Analysis
Like (3)
Save
Tweet
Share
7.25K Views

Join the DZone community and get the full member experience.

Join For Free

In 2017, around 60 remote code execution (RCE) deserialization vulnerabilities were reported, not including deserialization issues that only impact the availability of a system (Denial-of-Service), according to cvedetails.com. To date, in 2018, more than 80 such vulnerabilities have been reported. In the past, WebLogic, Oracle’s Enterprise Java application server, has been extensively patched against deserialization issues. The latest October 2018 Oracle Critical Patch Update (CPU) fixes another series of deserialization issues in WebLogic.

Because of this, I am often asked why Java deserialization vulnerabilities are being discovered so frequently? Is there a fundamental design flaw somewhere?

There are several reasons why deserialization issues keep arising.

First and foremost, it is essential to understand that deserialization vulnerabilities occur due to the combination of two fundamental design flaws. To begin with, some serialization/deserialization specifications and implementations, such as the native Java serialization mechanism, were designed with no way to validate the expected object type before the deserialization process. The Java runtime system will happily deserialize (convert to an object) any serialized stream without first validating its content and/or the expected types. The other design flaw is at the application level. If the serialization mechanism or the runtime system does not validate the serialized stream, then the application must not expose deserialization end-points to unsafe inputs. The deserialization end-points must not be accessible by untrusted users. This is why the vulnerability is officially named “Deserialization of untrusted data."

The Java Virtual Machine (JVM) has only recently offered support for a new mechanism that allows developers and security engineers to protect deserialization end-points by enforcing type filtering. However, this introduced another layer of complexity around the already confusing nature of the vulnerability.

This brings us to the second reason why deserialization issues keep arising. This unsafe process had not been (and possibly still is not) comprehensively understood by software developers who have designed their applications to expose deserialization components to potentially unsafe, user-controlled, serialized streams.

Even when the vulnerability is fully understood by the software developers, the issue might not be properly remediated. Since it is a design flaw, in many cases, it can be very costly and complex to make changes in the code, as it could even require a redesign of part of the system. This complexity sometimes forces developers to cut corners and mitigate the vulnerability using a blacklist approach, which is an easy way to block known exploits. However, even though blacklisting may help mitigate known exploits, it is prone to new attack vectors.

Third, security researchers are attracted by the challenge of bypassing security mechanisms that depend on simplistic controls such as blacklists, which in most cases are incomplete. The challenge becomes increasingly attractive if the blacklist mechanism protects a high-value target such as application servers (e.g. WebLogic).

The final reason that makes this type of vulnerability attractive to researchers is because of its high impact and severity. In most cases, deserialization vulnerabilities could allow attackers to perform remote code execution without authentication. Such an attack could take over the victim's system and potentially even compromise the whole network.

It should be noted that the above applies to deserialization vulnerabilities that allow remote code execution. There is another type of deserialization issue that has a different impact, namely Denial-of-Service, often via unrestricted memory allocation. This type of deserialization issue generally doesn't require a redesign of the application and, in most cases, can be fixed or mitigated by simply patching the code to properly do input validation of the expected size of memory that should be allocated. However, there are exceptions to this rule, as there are known Denial-of-Service deserialization exploits that cannot be fixed by simply patching the application code. Because of its reduced impact, this type of deserialization vulnerabilities is less popular targets for security researchers.

To be clear, deserialization vulnerabilities are primarily caused by design flaws at the serialization and application levels, and they are not code-level bugs. The best way to avoid deserialization vulnerabilities is to design applications in such a way that does not perform open-ended object deserialization of untrusted data.

Changing the serialization format to XML or JSON does not necessarily eliminate deserialization issues, as there are known deserialization vulnerabilities with these formats and libraries as well. If changing the source code is not feasible or redesigning the application is not an option and usage of blacklists and whitelists is not desired, there are RASP solutions that can protect against such issues with no code or design changes and without depending on heuristic approaches.

Vulnerability application Design Runtime system Java (programming language) Java virtual machine security dev

Opinions expressed by DZone contributors are their own.

Popular on DZone

  • Why Does DevOps Recommend Shift-Left Testing Principles?
  • How to Develop a Portrait Retouching Function
  • Public Cloud-to-Cloud Repatriation Trend
  • A Real-Time Supply Chain Control Tower Powered by Kafka

Comments

Partner Resources

X

ABOUT US

  • About DZone
  • Send feedback
  • Careers
  • Sitemap

ADVERTISE

  • Advertise with DZone

CONTRIBUTE ON DZONE

  • Article Submission Guidelines
  • Become a Contributor
  • Visit the Writers' Zone

LEGAL

  • Terms of Service
  • Privacy Policy

CONTACT US

  • 600 Park Offices Drive
  • Suite 300
  • Durham, NC 27709
  • support@dzone.com
  • +1 (919) 678-0300

Let's be friends: