3 ms·

As per the PoC, yes — this is the usual Java Deserialization RCE where it’ll instantiate arbitrary classes. Java serialization really is a gift that keeps on gi

As per the PoC, yes — this is the usual Java Deserialization RCE where it’ll instantiate arbitrary classes. Java serialization really is a gift that keeps on giving.

stefan_ 2y ago
I love how these always instantly escalate into trivial code execution / reverse shell. Remember kids, C is the enemy! The "fix" in question also screams "delete this crap immediately": https://github.com/wgtmac/parquet-mr/commit/d185f867c1eb968ac6de5024c70de2aa3b923ec2 https://github.com/wgtmac/parquet-mr/commit/d185f867c1eb968a...
- pclmulqdq 2y ago
  This is a bug in Java. Java is considered "memory safe" because of its GC and its VM. This is not a memory safety bug.
  - chowells 2y ago
    It's true. No memory is being used in contravention of the language semantics. Absolutely memory safe.
- hinkley 2y ago
  The fix still loads the class before checking if it’s okay. That’s a smaller attack window but it’s still not zero.
  - josefx 2y ago
    Java reflection can load classes without initializing them, so no untrusted code would have to be executed at that point.
    - hinkley 2y ago
      I haven’t been in Java for a good while. When did they do that? Static initializers used to load on Classloader calls.
      - josefx 2y ago
        An overload for Class.forName with an explicit initialize parameter was added in Java 1.2 .
        hinkley 2y ago
        Except they don't call Class.forName(..., false, ...) anywhere in the codebase, so my original comment still stands.
deleted 2y ago
[deleted]