Hazelcast is vulnerable to untrusted deserialization remote code execution

[drosenbauer]

I emailed the support address on April 17 and received a response indicating that I should report my findings here. So here we are.

The Hazelcast cluster join procedure is vulnerable to remote code execution due to Java deserialization. If an attacker can reach a listening Hazelcast instance with a crafted JoinRequest, and vulnerable classes are also on the classpath, the attacker can run arbitrary shell commands (among other nefarious things). Hazelcast will blindly deserialize any object it receives in that request stream. Since the JoinRequest is what implements authentication, this is necessarily pre-authentication.

This was verified against the latest code from the Git repository, as well as releases 3.7 and 3.2.1.

I have a small whitelist/blacklist filter patch that I can submit a PR for, once I'm cleared to do so. I've already emailed the signed form. Or if you have another solution, feel free!

If you choose to go the filtering route, the Hazelcast team should probably create a default whitelist for serialization, because blacklists are almost always out of date as soon as they are created.

[houey]

any progress on this issue?

[kwart]

The issue is not resolved yet. Users using Enterprise edition can avoid the untrusted deserialization in member joining procedure by

• either enabling symmetric encryption;
• or configuring TLS with mutual authentication

If the member discovery mode is UDP multicast, then only the symmetric encryption avoids the abuse.

[jerrinot]

Once more thanks for reporting the issue. #12230 is addressing it. It allows to define black/while lists for deserialization.

[martinfurmanski]

Could we get this ported to 3.7 release branch?

[anuragpathak2608]

@drosenbauer , do you have any data to pentest hazlecast publicly open port?

[peterchenadded]

Can someone confirm @kwart comment?

[kwart]

@peterchenadded are you asking for attack ready data? No, I don't provide such data.

[peterchenadded]

@kwart No I mean does enabling SSL/encryption actually prevent the vulnerability? Can someone confirm?

Also the cve states that's it's vulnerable in hazelcast 3.10.x but wasn't the blacklist/whitelist feature to prevent the issue added in 3.10.0, just that you had to manually enable it.

[kwart]

@peterchenadded The SSL/TLS with mutual authentication requires client to authenticate with its valid certificate. If the client successfully authenticates, then it's considered a trusted one (i.e. not a one who would attack deserialization routines). No deserialization takes place before TLS is fully established. When using TLS it's necessary to disable the multicast discovery because TLS is TCP-based and multicast works over the UDP.

Similar protection works for symmetric encryption. Nevertheless, there is another issue - symmetric encryption only works between member nodes, so client protocol can't be protected by this approach.

The fix was introduced in 3.11 and part of it is backported to 3.10.1. The backport is configured by Hazelcast properties - see https://docs.hazelcast.org/docs/3.10.5/manual/html-single/index.html#untrusted-deserialization-protection

[peterchenadded]

@kwart thanks for the clear explanation. The cve read like it was possible.

Good to know it's not with the enterprise license if additional security settings are configured.