security: implement look-ahead allowlist to block RCE gadgets#544
security: implement look-ahead allowlist to block RCE gadgets#544missoum1307 wants to merge 1 commit intogoogle:masterfrom
Conversation
|
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. |
694789e to
974d915
Compare
|
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. |
|
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 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. |
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