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

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

Closed
cowtowncoder opened this issue May 11, 2019 · 12 comments · Fixed by apache/kafka#6798
Closed

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

cowtowncoder opened this issue May 11, 2019 · 12 comments · Fixed by apache/kafka#6798
Labels
CVE Issues related to public CVEs (security vuln reports)
Milestone

Comments

@cowtowncoder
Copy link
Member

cowtowncoder commented May 11, 2019

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 cowtowncoder added 2.9 CVE Issues related to public CVEs (security vuln reports) labels May 11, 2019
@cowtowncoder cowtowncoder changed the title Possible new CVE wrt Polymorphic typing (placeholder) Block one more gadget type (CVE-2019-12086) May 14, 2019
@cowtowncoder cowtowncoder added this to the 2.9.9 milestone May 14, 2019
@cowtowncoder
Copy link
Member Author

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
Copy link

0x554simon commented May 17, 2019

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

@cowtowncoder
Copy link
Member Author

@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
Copy link

tcherel commented May 21, 2019

@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
Copy link
Member Author

@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
Copy link

tcherel commented May 21, 2019

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

jvz added a commit to jvz/jackson2-api-plugin that referenced this issue May 21, 2019
@cowtowncoder
Copy link
Member Author

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

  1. 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
Copy link

tcherel commented May 21, 2019

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
Copy link

Do you plan to backport this to 2.7?

ijuma added a commit to ijuma/kafka that referenced this issue May 23, 2019
ijuma added a commit to apache/kafka that referenced this issue May 24, 2019
ijuma added a commit to apache/kafka that referenced this issue May 24, 2019
@cowtowncoder
Copy link
Member Author

No backporting to versions prior to 2.9.x planned.

@MaximilianTews
Copy link
Contributor

MaximilianTews commented May 28, 2019

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;
}

haidangdam pushed a commit to haidangdam/kafka that referenced this issue May 29, 2019
@cowtowncoder
Copy link
Member Author

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.

candrews added a commit to candrews/glassfish that referenced this issue Jun 6, 2019
candrews added a commit to candrews/glassfish that referenced this issue Jun 6, 2019
candrews added a commit to candrews/glassfish that referenced this issue Jun 6, 2019
pengxiaolong pushed a commit to pengxiaolong/kafka that referenced this issue Jun 14, 2019
bshannon pushed a commit to eclipse-ee4j/glassfish that referenced this issue Jun 18, 2019
@cowtowncoder cowtowncoder changed the title Block one more gadget type (CVE-2019-12086) Block one more gadget type (mysql, CVE-2019-12086) Sep 12, 2019
ablekhman added a commit to atlassian/jackson-1 that referenced this issue Oct 23, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
CVE Issues related to public CVEs (security vuln reports)
Projects
None yet
Development

Successfully merging a pull request may close this issue.

5 participants