You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.