Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Possible DoS if using JDK serialization to serialize JsonNode [CVE-2021-46877] #3328

Closed
cowtowncoder opened this issue Nov 20, 2021 · 21 comments
Labels
2.13 For issues planned for 2.13 CVE Issues related to public CVEs (security vuln reports)
Milestone

Comments

@cowtowncoder
Copy link
Member

cowtowncoder commented Nov 20, 2021

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.

@cowtowncoder cowtowncoder added to-evaluate Issue that has been received but not yet evaluated 2.13 For issues planned for 2.13 CVE Issues related to public CVEs (security vuln reports) and removed to-evaluate Issue that has been received but not yet evaluated labels Nov 20, 2021
@plokhotnyuk
Copy link

plokhotnyuk commented Nov 20, 2021

@cowtowncoder Please contact me if it will require any help with a fix implementation.

@cowtowncoder
Copy link
Member Author

@plokhotnyuk Thank you. I think I know how to handle this as it is sort of similar to some issues with CBOR/Smile codecs. But if you are interested and have time, I would definitely accept help!

Since I do not want to publicly disclose details yet, could you email me (tatu at fasterxml dot com) and I can share the details, as well as my idea of the fix?
Or if you want to join:

https://groups.google.com/g/jackson-dev-infosec

I can share details there as well?

@cowtowncoder
Copy link
Member Author

cowtowncoder commented Dec 8, 2021

Fix implemented, fwtw; backported for inclusion in:

  • 2.12.6 (released 15-Dec-2021)
  • 2.13.1

@freemanzMrojo
Copy link

@cowtowncoder do you have an estimation about when this fix is gonna be released in those versions? Thanks in advance.

@jphelp32
Copy link

@cowtowncoder do you plan to fix this for 2.11?

@cowtowncoder
Copy link
Member Author

cowtowncoder commented Dec 13, 2021

@freemanzMrojo Hoping to release 2.12.6 some time this week; 2.13.1 at earlier this weekend but we'll see. My non-paid OSS work time is severely limited these days, and esp. so on holiday times.

@jphelp32 No, neither 2.11 nor 2.10.

I'll add a note to mention that this only affects versions 2.10.0 + (2.9.x and earlier not affected).
Also worth note: it is very unlikely this actually affects anyone; but I can only explain why after patch is released.

@beedle-
Copy link

beedle- commented Dec 14, 2021

Hi @cowtowncoder , thanks a lot for your work.
I don't see the 2.14.0 artifact in maven central, any idea why it's not available ?

@yawkat
Copy link
Member

yawkat commented Dec 14, 2021

@beedle- there is no 2.14 release yet.

@devkhatri9
Copy link

@cowtowncoder Because of vulnerability in jackson databind 2.12.5 version, I have been assigned the task to fix this issue asap,
can you please give me an estimate , when you are planning to release version 2.12.6 and 2.13.1.
If it doesn't get fixed by this week, I might have to use some alternative jar.

Thanks in advance

@cowtowncoder
Copy link
Member Author

@devkhatri9 I am hoping to release 2.12.6 this week; 2.13.1 after that. But I am not paid for work related to Jackson so my daytime job has priority here which means that I do it when I have time to do it.
Fix itself is in code base if you want to do a local build.

It is also bit unfortunate that the whole Security Scare Business has cropped up to spread FUD -- this issue, for example is unlikely to affect sizable part of user base at all. Yet everyone is scrambling because CVE is filed and tooling is alarming and alerting everyone regardless. Since tooling cannot really determine applicability by any means other than version number, black-and-white, on/off criteria.

@ffallas
Copy link

ffallas commented Dec 15, 2021

Hello team, any update on this?

@cowtowncoder
Copy link
Member Author

2.12.6 was just released last night. Will need to address an issue wrt 2.13 but hoping to follow up with 2.13.1 within a week.

After this I can disclose more about vulnerability which (IMO) is not really very significant, not widely applicable. But, you know, being filed must be addressed.

@ovanekem
Copy link

Thanks for the release. I think indeed the whole discussion here started because the vulnerability has been assessed at CVSS 7.5 (HIGH) by jFrog in XRay and this might have been overestimated.
Thanks for the good work on Jackson !!

@cowtowncoder
Copy link
Member Author

Hmmmh. 7.5 sounds ridiculously high -- but it is easier to re-classify knowing the details once I fill them in.
Attacker must know a few details of usage and be able to provide in not JSON (or any other external format Jackson supports) but actual JDK serialization payload, knowing system somehow tries to use JDK serialization related to one of types Jackson supports. This is a lot of ifs and I'd be surprised if anyone anywhere could actually exploit it to cause increased memory usage (JVM OOMEs).

@yawkat
Copy link
Member

yawkat commented Dec 16, 2021

tbh, no exploit requiring an attacker-controlled jdk serialization payload should be rated with that high severity...

@ovanekem
Copy link

I totally agree, internally I did lower the priority (but of course I had to provide argumentation ;-)).
For info, that is how it has been categorised in jFrog's xray:

Xray ID XRAY-191477 
Severity High
CVSS Score 7.1 (v2) 7.5 (v3)

@cowtowncoder cowtowncoder added this to the 2.12.6 milestone Dec 19, 2021
@cowtowncoder
Copy link
Member Author

2.13.1 was just released as well so fix available for 2.12 and 2.13. I will try to write actual vuln description tomorrow if I have time.

@cowtowncoder cowtowncoder changed the title Possible DoS issue Possible DoS if using JDK serialization to serialize JsonNode Dec 19, 2021
@cowtowncoder
Copy link
Member Author

Updated description; please LMK if it does (or esp. if does not) make sense.

@cowtowncoder
Copy link
Member Author

@ovanekem do you happen to know of an official CVE requested? Or any public identifier that I could use.

@cowtowncoder cowtowncoder changed the title Possible DoS if using JDK serialization to serialize JsonNode Possible DoS if using JDK serialization to serialize JsonNode [CVE-2021-46877] Mar 24, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
2.13 For issues planned for 2.13 CVE Issues related to public CVEs (security vuln reports)
Projects
None yet
Development

No branches or pull requests

10 participants