I woke this morning to an email linked to a blog post warning me if I’m using Java, this is the next heartbleed bug I need to be worried about. That’s a pretty serious headline, so I checked out the post.
For those not familiar with the heartbleed bug, it was a pretty significant vulnerability in OpenSSL allowing attackers to run code on the server. OpenSSL is a popular open source library, used in many flavors of linux, and used by web servers to support https communications. Thousands of applications were affected. Hundreds of thousands (perhaps millions) of web sites were left vulnerable. The heartbleed bug was serious business. Internet facing machines could be compromised. This last part is very important about the serious nature of the heartbleed bug, since the vulnerability could be exploited from the internet.
Java Serialization Exploits
Serialization in Java has long been known as a dance with the devil. In a nutshell, you’re taking a Java object, saving that object and its current state in binary format, transmitting the binary content to another server (and JVM), then restoring the object. The Java “heartbleed” exploit works by manipulating the binary content of the serialized object, then sending it to the receiving JVM. The unsuspecting JVM can then be tricked into executing code injected by the attacker.
A popular library from Apache is vulnerable to being compromised. The Apache Commons Collections library is used in a number of popular Java application servers and applications. This library is of particular concern because code is executed when the library deserializes objects. But this is just one feature of the library. A large part of its usage is around Java collections. You’ll find Apache Commons Collections in the dependencies of many Spring projects, but the vulnerable InvokerTransformer class is not used by Spring.
The only internet facing threat I know of is the practice of storing Serialized Java objects as cookies on the client. Let me be blunt, if you’re not encrypting the binary cookie databefore you send it to the client, you’re an idiot and deserve to get hacked.
The rest of the exploits I looked at required access to the network behind the internet firewall. This is a significant reduction in the threat. If an attacker is inside your internet firewall, you’ve already been compromised.
Okay, let’s say the attacker is inside, now the server needs to be listening for, and accepting serialized objects on a network port. Fairly common for RMI. And yes, this can be exploited.
Java Serialization Exploits in the Modern Enterprise
But now let’s look at the modern enterprise. Compliance with regulations such as PCI, SOX, and SAS-70 have driven a number of security measures into the enterprise.
For example, PCI compliance is a fan of encrypting data in flight. Just by encrypting the communication channel neuters this exploit.
But compliance doesn’t stop there. In the old days, I could get on the corporate network and access production systems. As long as I was on the network, I could get to the servers. Even ‘sniff’ for traffic going to said production servers.
Not anymore. Modern production systems live in private networks. Often the networks are layered. They are firewalled to minimal access. If you have a memcache server, only the associated application servers will be allowed to communicate with it. Disgruntled Sally hacker on her PC in the call center will not have network access to the production servers.
Keep in mind, I’m referring to large enterprises. You still see a lot more security hardening in the financial services sector than you do in other industries, such as retail. But regulatory compliance is driving even retailers to adopt better IT security practices. (Target hack anyone?) A small business is not going to have the depth on the IT bench as a large business, but it’s still no excuse to not follow best practices.
Java Serialization Risks and the Spring Framework
As I mentioned above, Spring does not use Apache Commons Collections, and does not use the Apache InvokerTransformer class. But this vulnerability is specific to Java serialization, and not limited to the Apache InvokerTransformer class. The Spring team did identify a similar risk in the Spring Framework code. This has been fixed in Spring versions 4.1.9 and 4.2.3. You can read details about the fix here.
Java Heartbleed Bug?
But is this the Java “heartbleed” bug? No, not even close. The risk is nowhere close to the original heartbleed bug. Let me be even more blunt. If you’re not following best practices in your coding, and you’re not adopting IT security best practices popularized by PCI, SOX, and SAS-70 compliance – you’re a lazy moron and deserve to get hacked.
People referring to this as Java’s heartbleed bug are overly alarmist. It is a vulnerability we need to be aware of. Good coding practices and IT security best practices significantly mitigate the risks in Java serialization.
In Java development, you’re also seeing a move away from using RMI and serialization in general. For RMI, the trend is to use web services, in which the object is converted to XML or JSON. For JMS, you often see XML or JSON again over serialized objects. JMX, that is going to be secured.
This is not Java’s heartbleed bug. Millions of websites are not as risk. The risk from internet exposed machines is small. Risks around Java serialization are very narrow. There are very specific use cases you need to be concerned with. Relax, the sky isn’t falling. Whew.