Block one more gadget type (mysql, CVE-2019-12086)

[cowtowncoder]

A new gadget type (see https://medium.com/@cowtowncoder/on-jackson-cves-dont-panic-here-is-what-you-need-to-know-54cd0d6e8062) was reported, and CVE id allocated was CVE-2019-12086.
CVE description is available at: https://nvd.nist.gov/vuln/detail/CVE-2019-12086 for full details, but the specific variation (in addition to needing "default typing", attacker being able to craft specific json message) is that:

• If service has jar mysql-connector-java in its classpath

vulnerability applies, and attacker is able to read arbitrary files from service's local file system.

Original vulnerability discoverer: 618 from College of software, Nankai University

---

Fixed in:

• 2.9.9 and later
• 2.8.11.4
• 2.7.9.6
• 2.6.7.3

[cowtowncoder]

Fixed this in2.9 (for 2.9.9) and backported in 2.8 as well in case 2.8.11.4 might be released (no plans at this point). Will be included in later versions like 2.10.0 and 3.0 as well.

[0x554simon]

Is this fix included in 2.9.9? I didn't find any information about this in Release note.

[cowtowncoder]

@0x554simon yes it is. Thank you for pointing out it was missing from release notes file, even tho it was included on release page (https://github.com/FasterXML/jackson/wiki/Jackson-Release-2.9.9)

[tcherel]

@cowtowncoder https://nvd.nist.gov/vuln/detail/CVE-2019-12086 is saying/suggesting that the vulnerability can be exploited only if the mysql-connector-java jar 8.0.14 or earlier is in the classpath.
But I do not see any differences between the com.mysql.cj.jdbc.admin.MiniAdmin class in the mysql-connector-java jar 8.0.14 or the latest one (8.0.16).

[cowtowncoder]

@tcherel I based CVE on report I received which seemed to indicate something had been fixed but I did not verify difference myself. So I wonder if original reporter included latest version that had the problem and assumed (or implied) that fix would be in next version?

[tcherel]

Thanks @cowtowncoder. Do you have an email or contact info that I can use to reach out to the original reporter?

[cowtowncoder]

Original reporter here refers to person who sent me the information: I filed for CVE.
But the link included was to:

http://russiansecurity.expert/2016/04/20/mysql-connect-file-read/

with instructions that included

2. When mysql client connect to a mysql server with MySQL Connector/J before version 8.0.15 released at 2019-02-01, mysql server is able to read arbitrary local file from mysql client.

[tcherel]

I see. I think I figured out why it is not exploitable with 8.0.15 or higher.
From https://dev.mysql.com/doc/relnotes/connector-j/8.0/en/news-8-0-15.html:

Default value of the connection property allowLoadLocalInfile has been changed to false.
Applications that use the LOAD DATA LOCAL INFILE statement on MySQL Server needs to set this property to true explicitly. (Bug #29261254)

Thanks for the help.

[Vervious]

Do you plan to backport this to 2.7?

[cowtowncoder]

No backporting to versions prior to 2.9.x planned.

[MaximilianTews]

Hi @cowtowncoder,

I found this on the web https://medium.com/@cowtowncoder/on-jackson-cves-dont-panic-here-is-what-you-need-to-know-54cd0d6e8062 that seems written by you.

I am wondering if (3) under "What to do to Protect My System?" is also a valid protection against CVE-2019-12086. I assume it is. But I want to double check. If I read the description of the CVE (https://nvd.nist.gov/vuln/detail/CVE-2019-12086) it does not name (3) as a protection.

Also could you please tell me if classes with @JsonTypeInfo (or subclasses of them) with properties of type Object are affected if they are annotated with @JsonIgore? For example, would the following be vulnerable:

@JsonTypeInfo(...)
@JsonSubTypes(...)
class Test {
...
}

class SubTest extends Test {
   @JsonIgnore
   Object myObject
}

And my last question: would a class be vulnerable if the class does not have a property of type object directly but indirectly? I assume it is. But I want to double check. For example, would the following be vulnerable:

@JsonTypeInfo(...)
@JsonSubTypes(...)
class Test {
...
}

class SubTest extends Test {
   MyClass myClass;
}

class MyClass {
   Object test;
}

[cowtowncoder]

First of all: yes, that blog entry covers this CVE as well, there is nothing special (I'll need to add more detail here).

Second: members of polymorphic types DO NOT automatically inherent polymorphic handling -- so Object fields are not polymorphic by default unless either

1. default typing is enabled (for category that includes java.lang.Object), or
2. there is @JsonTypeInfo for that property

So neither of your cases is affected by any of these CVEs. In fact, even Test is fine unless there was a gadget class that extended this type (i.e. you managed to create a class that is subtype of Test and exposes a security vulnerability similar to types block-listed).

I hope this helps.