Skip to content

security: implement look-ahead allowlist to block RCE gadgets#544

Open
missoum1307 wants to merge 1 commit intogoogle:masterfrom
missoum1307:fix-deserialization-vulnerability
Open

security: implement look-ahead allowlist to block RCE gadgets#544
missoum1307 wants to merge 1 commit intogoogle:masterfrom
missoum1307:fix-deserialization-vulnerability

Conversation

@missoum1307
Copy link
Copy Markdown

This PR addresses a vulnerability where OpenedSocket performs unauthenticated deserialization.

I have introduced a SafeObjectInputStream that implements a strict look-ahead allowlist. This ensures only expected internal bridge classes and safe standard Java types are instantiated, effectively mitigating RCE/SSRF risks from untrusted gadget chains (e.g., PriorityQueue).
Verified locally by confirming that authorized messages pass through while unauthorized gadgets trigger an InvalidClassException.

Google VRP report: https://issuetracker.google.com/issues/496900523

@google-cla
Copy link
Copy Markdown

google-cla bot commented Mar 28, 2026

Thanks for your pull request! It looks like this may be your first contribution to a Google open source project. Before we can look at your pull request, you'll need to sign a Contributor License Agreement (CLA).

View this failed invocation of the CLA check for more information.

For the most up to date status, view the checks section at the bottom of the pull request.

@missoum1307 missoum1307 force-pushed the fix-deserialization-vulnerability branch from 694789e to 974d915 Compare March 28, 2026 12:00
Copy link
Copy Markdown
Author

@missoum1307 missoum1307 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

please review.

@cgdecker
Copy link
Copy Markdown
Member

cgdecker commented Apr 3, 2026

I'm not sure there's any danger with what we're doing here because our socket connections aren't with arbitrary services, they're local connections between processes controlled by Caliper. In addition, the connections are only opened when the worker process sends a UUID that the runner (host) process provides when starting the process or Android activity. I can't see the contents of the VRP report, but I see it's closed as WAI. This change also doesn't seem to pass CI because it doesn't account for all of the actual implementation classes being serialized.

@missoum1307
Copy link
Copy Markdown
Author

missoum1307 commented Apr 4, 2026

VRP report is only accepted when they developer decide to merge the fix.

While ServerSocketService validates the UUID for every connection, it provides no protection once that handshake is complete. The current logic assumes that any process possessing the UUID is inherently trustworthy. My PR addresses the risk that a UUID could be leaked or intercepted.

// Also ServerSocketService.java

@OverRide
protected void startUp() throws Exception {
serverSocket = new ServerSocket(caliperOptions.localPort());
}

When you only provide a port (like new ServerSocket(0)), Java binds to 0.0.0.0 by default. This means the socket listens on every network interface, including your Wi-Fi or Ethernet IP. in a a big organizaion/compnay, it is much relaxed to share.

"This change also doesn't seem to pass CI", if you decide that it worth fixing , please the add the missing classes.

I have POC of this RCE, ill send it in priavate channel. the scenario is that we have uuid.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants