jackson-databind 2.10.x through 2.12.x before 2.12.6 and 2.13.x before 2.13.1 allows attackers to cause a denial of service (2 GB transient heap usage per read) in uncommon situations involving JsonNode JDK serialization.
cpe:2.3:a:fasterxml:jackson-databind:*:*:*:*:*:*:*:*
439EA36C-3D2E-4B27-B36B-AECEC34E0D8A
2.12.6
2.10.0
cpe:2.3:a:fasterxml:jackson-databind:2.13.0:-:*:*:*:*:*:*
28B35307-C357-43CD-9201-52974EB429EC
cpe:2.3:a:fasterxml:jackson-databind:2.13.0:rc1:*:*:*:*:*:*
F2CB4DE8-6230-4E88-98B0-F94C87B1ED29
cpe:2.3:a:fasterxml:jackson-databind:2.13.0:rc2:*:*:*:*:*:*
F4EC2939-0A70-4587-B14A-335D62C3F901
OR
There is a report on possible DoS attack, against certain versions of Jackson 2.10.x - 2.13.x (does not affect earlier versions like 2.9, nor future 2.14 and 3.0).

CVE: https://nvd.nist.gov/vuln/detail/CVE-2021-46877

Fix has been included in versions:

* 2.12.6
* 2.13.1

No current plans to back-porting into 2.10 or 2.11 branches (2.9 and earlier not affected).

------

# CVE description

## Applicability

The vulnerability is available only when using _JDK serialization_ to serialize, deserialize `JsonNode` values: this is not something most users ever do, nor is it recommended for general usage.

So, any other use of `JsonNode` is completely unrelated to the reported CVE: this ONLY APPLIES WITH JDK SERIALIZATION.

## Example

So how does one use JDK Serialization with Jackson's `JsonNode`?

Example of such usage (copied from test `NodeJDKSerializationTest.java`) is:

```
ObjectNode root = MAPPER.createObjectNode();
root.put("answer", 42);
// Instead of usual "write as JSON" (using "node.toString()" or serialize using ObjectMapper)
// something wants to use JDK serialization: some caching frameworks do this

ByteArrayOutputStream bytes = new ByteArrayOutputStream();
ObjectOutputStream obOut = new ObjectOutputStream(bytes);
obOut.writeObject(root);
obOut.close();
byte[] jdkSer = bytes.toByteArray();

// and somewhere something wants to read it back like so:
ObjectInputStream objIn = new ObjectInputStream(new ByteArrayInputStream(jdkSer));
ObjectNode fromSer = (ObjectNode) objIn.readObject();

// ^^^^ to cause DoD, attacker would need to produce a specifically changed version of
//    payload!
```

The issue with JDK serialization is due to combination of format used and original code (see class `NodeSerialization` for  details).

First: `JsonNode` is serialized as a sequence of bytes where first 4 bytes indicate length of actual content; and contents are JSON serialization itself. When reading it back (JDK deserialization) length is read first, original code allocates a `byte[]` with that size, and then contents are read. This works, functionally speaking.

But if attacker provides, instead, a payload that contains only 4-byte length, with value of `Integer.MAX_VALUE`, then decoder will:

1. Read the length
2. Allocate 2 gig `byte[]` array
3. If it succeeds, try to read contents, fail

The problem here is that during step (2), a large buffer allocation may well run process out of (heap) memory -- especially so if attacker manages to inject multiple broken messages.

Fix is to avoid eager allocation of big buffers and only allocate buffers as needed, along reading of the payload.







Possible DoS if using JDK serialization to serialize `JsonNode` [CVE-2021-46877]
This is a GitHub Issue
repo:jackson-databind
owner:FasterXML
Title : Possible DoS if using JDK serialization to serialize `JsonNode` [CVE-2021-46877]
Issue date:

--- start body ---
There is a report on possible DoS attack, against certain versions of Jackson 2.10.x - 2.13.x (does not affect earlier versions like 2.9, nor future 2.14 and 3.0).

CVE: https://nvd.nist.gov/vuln/detail/CVE-2021-46877

Fix has been included in versions:

* 2.12.6
* 2.13.1

No current plans to back-porting into 2.10 or 2.11 branches (2.9 and earlier not affected).

------

# CVE description

## Applicability

The vulnerability is available only when using _JDK serialization_ to serialize, deserialize `JsonNode` values: this is not something most users ever do, nor is it recommended for general usage.

So, any other use of `JsonNode` is completely unrelated to the reported CVE: this ONLY APPLIES WITH JDK SERIALIZATION.

## Example

So how does one use JDK Serialization with Jackson's `JsonNode`?

Example of such usage (copied from test `NodeJDKSerializationTest.java`) is:

```
ObjectNode root = MAPPER.createObjectNode();
root.put("answer", 42);
// Instead of usual "write as JSON" (using "node.toString()" or serialize using ObjectMapper)
// something wants to use JDK serialization: some caching frameworks do this

ByteArrayOutputStream bytes = new ByteArrayOutputStream();
ObjectOutputStream obOut = new ObjectOutputStream(bytes);
obOut.writeObject(root);
obOut.close();
byte[] jdkSer = bytes.toByteArray();

// and somewhere something wants to read it back like so:
ObjectInputStream objIn = new ObjectInputStream(new ByteArrayInputStream(jdkSer));
ObjectNode fromSer = (ObjectNode) objIn.readObject();

// ^^^^ to cause DoD, attacker would need to produce a specifically changed version of
//    payload!
```

The issue with JDK serialization is due to combination of format used and original code (see class `NodeSerialization` for  details).

First: `JsonNode` is serialized as a sequence of bytes where first 4 bytes indicate length of actual content; and contents are JSON serialization itself. When reading it back (JDK deserialization) length is read first, original code allocates a `byte[]` with that size, and then contents are read. This works, functionally speaking.

But if attacker provides, instead, a payload that contains only 4-byte length, with value of `Integer.MAX_VALUE`, then decoder will:

1. Read the length
2. Allocate 2 gig `byte[]` array
3. If it succeeds, try to read contents, fail

The problem here is that during step (2), a large buffer allocation may well run process out of (heap) memory -- especially so if attacker manages to inject multiple broken messages.

Fix is to avoid eager allocation of big buffers and only allocate buffers as needed, along reading of the payload.







--- end body ---

comments :
--- start comments ---

--- end comments ---