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. Software Design and Architecture
  3. Security
  4. Java Serialization Vulnerability Threatens Millions of Applications

Java Serialization Vulnerability Threatens Millions of Applications

Contrast security is promoting their solution for a vulnerability that affects WebLogic, WebSphere, JBoss, Jenkins, and OpenNMS.

Jeff Williams user avatar by
Jeff Williams
·
Nov. 12, 15 · News
Like (3)
Save
Tweet
Share
11.27K Views

Join the DZone community and get the full member experience.

Join For Free

A widespread vulnerability in Java environments leaves thousands of businesses seriously exposed. Despite lacking a clever name — ala Heartbleed, Shellshock, and POODLE — this vulnerability is poised to allow hackers to do damage across the Internet. And there’s no easy  way to protect applications en-masse. That means it will take organizations a long time to find and fix all the different variants of this vulnerability.

Contrast Security has a solution that uses our patented, powerful application security instrumentation platform to find and fix this problem both quickly and accurately. Contrast can identify this problem during development using our IAST (Interactive Application Security Testing) approach. And Contrast can also protect applications in production using our RASP (Runtime Application Self Protection) features to patch the problem immediately or generate security alerts, with no re-coding necessary. One Contrast agent installed on an application server can address the problem on all of the Java applications on that server.

To learn more about the details of the Java serialization flaw, keep reading. Serialization is a way that developers turn their data structures into a stream of bytes for transport or storage.  Deserialization is the reverse process that happens when the data is received. There have been security issues with serialization for a long time - going back to 2010 and before.  See http://www.ibm.com/developerworks/library/se-lookahead for the full history.  Just recently, exploits were published for a bunch of different Java environments -- which unfortunately appears to be the only way to make something happen in security. 

These flaws are serious and can be used to effect a complete remote command execution -- total host takeover on any application that accepts serialized objects. 

In Java, reading a BitSet from a serialized stream is as simple as:

     ObjectInputStream in = new ObjectInputStream( inputStream );

     return (Data)in.readObject();

The problem is that there’s no way to know what you’re deserializing before you’ve decoded it.  So an attacker can serialize a bunch of malicious objects and send them to your application.  Once you call readObject(), it’s too late.  In some ways it’s like an XXE problem, where an attacker can use a malicious DOCTYPE to generate attacks during XML parsing.  But in this case, there’s no easy way to turn off DOCTYPE processing. 

What's need is a way to allow deserialization, but make it impossible for attackers to create instances of arbitrary classes.  Something like this:

      List<Class<?>> safeClasses = Arrays.asList( BitSet.class, ArrayList.class );

      Data d2 = safeReadObject( Data.class, safeClasses, new FileInputStream( f ) );

This allows the developer to specify the return type and a list of the classes that they expect to show up in serialized objects.  When something unauthorized shows up, we should throw a SecurityException and block the attempt.  Turns out that it’s not too difficult to implement such a thing.  We just need to overload a bit of the ObjectInputStream implementation.  

Here’s a method that you can use to replace calls to readObject:

    @SuppressWarnings("unchecked")

    public static <T> T safeReadObject(Class<?> type, List<Class<?>> safeClasses, InputStream in ) throws IOException, ClassNotFoundException {

        return (T) new ObjectInputStream(in) {

            protected Class<?> resolveClass(ObjectStreamClass d) throws IOException, ClassNotFoundException {

                Class<?> clazz = super.resolveClass(d);

                if (clazz.isArray()

                    || clazz.isPrimitive()

                    || clazz.equals(type)

                    || clazz.equals(String.class)

                    || Number.class.isAssignableFrom(clazz)

                    || safeClasses.contains(clazz)) return clazz;

                throw new SecurityException("Attempt to deserialize unauthorized " + clazz);

            }

        }.readObject();

    }

This method overrides the resolveClass() method in ObjectInputStream and adds checks to make sure that any class loaded as part of the deserialization process is either not exploitable or contained in the whitelist of safe classes.  As an alternative, you could also blacklist the classes you don’t know — the ones known to be used in exploits — but this approach is doomed to failure.  There are simply too many so-called “gadgets” on the classpath of a modern application to effectively list all the possible exploits.

This simple check protects your applications without radical changes to your code. The first step is to search your code to find all the places that you’re vulnerable —and tomorrow, all Contrast users will receive an update that does just that. You’ll be notified all the places across your application portfolio where you’re exposed due to deserializing untrusted data!

Application security Java (programming language) Vulnerability Serialization

Published at DZone with permission of Jeff Williams, DZone MVB. See the original article here.

Opinions expressed by DZone contributors are their own.

Popular on DZone

  • Select ChatGPT From SQL? You Bet!
  • How To Use Terraform to Provision an AWS EC2 Instance
  • How to Quickly Build an Audio Editor With UI
  • Building a Scalable Search Architecture

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: