Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Hazelcast is vulnerable to untrusted deserialization remote code execution #8024

Closed
drosenbauer opened this issue Apr 26, 2016 · 3 comments

Comments

Projects
None yet
5 participants
@drosenbauer
Copy link

commented Apr 26, 2016

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

This comment has been minimized.

Copy link

commented Mar 17, 2017

any progress on this issue?

@kwart

This comment has been minimized.

Copy link
Contributor

commented Jan 30, 2018

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

This comment has been minimized.

Copy link
Contributor

commented May 21, 2018

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

@jerrinot jerrinot closed this May 21, 2018

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.