Lucene search

K
seebugRootSSV:97076
HistoryJan 11, 2018 - 12:00 a.m.

Jackson-databind 远程代码执行漏洞(CVE-2017-17485)

2018-01-1100:00:00
Root
www.seebug.org
273

EPSS

0.493

Percentile

97.6%

jackson-rce-via-spel

An example project that exploits the default typing issue in Jackson-databind (https://github.com/FasterXML/jackson-databind)
via Spring application contexts and expressions

Context

The Jackson-databind project has a feature called default-typing (not enabled by default). When the target class has some
polymorph fields inside (such as interfaces, abstract classes or the Object base class), the library can include type info
into the JSON structure and use that info at unmarshalling. This can be dangerous when the input is controlled by an
attacker and the target class contains a field of type Object or something general (like Comparable).

How likely is this? I’m naive, so I hope Java developers don’t degrade a type-safe language to the level of an interpreted
type-unsafe language by (ab)using Objects as base classes… But I wouldn’t be surprised if one day some huge enterprise
software would be exploited one day via this vulnerability.

After the original discoveries (CVE-2017-7525) had been reported, the author patched this attack surface with a blacklist,
which was incomplete (as by nature of blacklists). This proof-of-concept project is a follow-up to demonstrate one more
way of exploitation; by abusing Spring classes via Jackson, this could lead to remote code execution. Note:
FileSystemXmlApplicationContext is happy to fetch the specified Spring context from anywhere, even from remote location
via http.

MITRE assigned CVE-2017-17485 to this vulnerability.

Affected versions

The following ones (inclusive) and older: 2.9.3, 2.7.9.1, 2.8.10

Mitigation

The fixed versions 2.7.9.2, 2.8.11 and 2.9.3.1 (which is to be released at time of writing these lines) expanded
the blacklist once again so that Spring application contexts cannot be instantiated anymore.

The new major version (3.x) of Jackson-databind will address this topic via a new API layer that provides a way
to achieve whitelisting-based serialization for these polymorph classes.