# Eclipse Deeplearning4j (.zip model) — unsafe Java deserialization (CWE-502) in `ModelSerializer` restore path: loading a malicious model executes attacker-controlled `ObjectInputStream.readObject`

## Summary

Eclipse **Deeplearning4j** model files are `.zip` archives loaded with `org.deeplearning4j.util.ModelSerializer.restoreMultiLayerNetwork(...)` / `restoreComputationGraph(...)`. On the **standard, default load path**, the restorer reads the archive entry **`preprocessor.bin`** and passes its bytes straight to **`new ObjectInputStream(...).readObject()`** with **no `ObjectInputFilter`, no class allowlist**. A malicious model `.zip` therefore drives **Java native deserialization of fully attacker-controlled bytes** the moment a victim loads it — a textbook **CWE-502** untrusted-deserialization sink, executing attacker code inside `readObject` (demonstrated below). Neither picklescan nor modelscan inspects Java-serialized data, so the malicious model passes both scanners.

## Affected / verified versions

- **deeplearning4j-nn / deeplearning4j-core 1.0.0-M2.1** (latest published release, Jan 2023) on **OpenJDK 21**
- Sink confirmed **identical and unpatched on `master`** (the restore helpers still call `ObjectInputStream.readObject` on `preprocessor.bin`)

## Root cause

`ModelSerializer.class` (bytecode, both `restoreMultiLayerNetwork` and `restoreComputationGraph` helpers):

```
319: ldc           "preprocessor.bin"
347: new           java/io/ObjectInputStream
353: invokespecial java/io/ObjectInputStream.<init>(InputStream)
360: invokevirtual java/io/ObjectInputStream.readObject()    // <-- unfiltered deser of attacker bytes
```

The archive member `preprocessor.bin` is deserialized via a raw `ObjectInputStream` with no `setObjectInputFilter`, no whitelist, no validation. This runs on **every** standard restore call, **independent of the `loadUpdater` flag** (only `updaterState.bin` is flag-gated, and it goes through `Nd4j.read`, not `readObject`). Java deserialization runs the graph's `readObject`/`readResolve`/finalize chains during reconstruction, so attacker-reachable gadget classes execute code **before** any type check on the result.

## Proof of concept

`poc/` contains the malicious model, a benign control, and the Java harness.

- `poc/malicious_model.zip` — a valid DL4J model (`configuration.json` + `coefficients.bin`) with one **added** `preprocessor.bin` holding a serialized object whose `readObject` runs `Runtime.exec`.
- `poc/Evil.java` — the demonstration gadget class (its `readObject` executes a command and writes a marker).
- `poc/Load.java` — `ModelSerializer.restoreMultiLayerNetwork(new File(argv[0]), true)` (the standard API call).
- `poc/benign_control.zip` — same model **without** `preprocessor.bin`.

### Observed (reproduced)

```
$ java -cp out:libs/* Load malicious_model.zip
MARKER_DL4J_DESER_7Q3X note=served-as-preprocessor.bin whoami=uid=1002(hacnho) gid=1002(hacnho) groups=...,docker,kvm
Exception in thread "main" java.lang.ClassCastException: class Evil cannot be cast to ...DataSetPreProcessor
```

The command executed **inside `readObject`** (marker written with the running uid) **before** the cosmetic `ClassCastException` — i.e. attacker code runs to completion during deserialization; the cast failure afterward is irrelevant. A real gadget chain returns a value of the expected type (or the exception is simply swallowed by the caller) and leaves no trace.

**Control:** `java -cp out:libs/* Load benign_control.zip` → `LOADED_OK params=23`, exit 0, no marker — isolating the sink to the attacker-added `preprocessor.bin`.

## Impact

Untrusted Java deserialization (CWE-502) on the default model-load path → **remote code execution** when a victim loads a malicious DL4J `.zip` model. This is the Java analog of the untrusted-pickle RCE class: the model file is attacker-controlled (the MFV threat model), and loading it deserializes attacker bytes through an unfiltered `ObjectInputStream`.

**Honest scope on the gadget precondition:** full host RCE requires a Serializable gadget chain reachable on the victim's classpath. The bare `deeplearning4j-core` dependency set ships `commons-collections4-4.1`, whose `InvokerTransformer` is **not** `Serializable` without `-Dorg.apache.commons.collections4.enableUnsafeSerialization=true`, and no other classic serializable-gadget library (commons-collections 3.x, commons-beanutils, c3p0, Spring, groovy, …) is in the default 172-jar set; JDK-21 serialization filters neutralize the JRE-internal chains. So on a **bare** library install the demonstrated impact is an **arbitrary-deserialization primitive** (CWE-502) that executes attacker code when a gadget is present (shown above with a class on the classpath). In practice DL4J is embedded in JVM applications/serving stacks that routinely pull gadget-bearing libraries (Spring, c3p0, commons-beanutils, etc.), making the precondition commonly satisfiable → RCE. The vulnerability is the unfiltered `readObject` sink itself; gadget availability is environmental and continually growing.

## Remediation

- Wrap the `preprocessor.bin` (and any other `readObject`) deserialization in a strict `ObjectInputFilter` allowlisting only the expected `org.nd4j…DataSetPreProcessor` types (and primitives), or replace native Java serialization with a safe format.
- Reject/serialize preprocessors via a schema-validated, non-`ObjectInputStream` mechanism.

## Dedup / novelty

- **No CVE / GHSA** for `ModelSerializer` Java deserialization at any version; **no huntr per-repo report** (`huntr.com/repos/…/deeplearning4j` shows only generic NPE/EOF bug reports). The sink is present and unpatched on `master`.
- Distinct from the other model-deserialization CWEs (pickle, etc.) — this is **Java native** `ObjectInputStream` on a `.zip` DL4J model, an in-scope huntr MFV format (`DL4J – Eclipse`).
- Scanner blind spot (bonus): `modelscan` → "No issues found"; `picklescan` → "Scanned files: 0" — neither understands Java `ObjectOutputStream` data.

## Artifacts

- `poc/malicious_model.zip`, `poc/benign_control.zip`, `poc/Evil.java`, `poc/Load.java`, `poc/MakeEvil2.java`.