0

The meta question here is that I'm trying to understand the risks to multitenant java applications from gadget chains.

For example, we're all familiar with the deserialization gadget that allows the creation of arbitrary java objects which can lead to RCE.

However, let's say your json deserializaer (or whatever) is securely configured. Is it possible to create gadget chains which re-configure jackson at runtime to be insecurely configured?

More generally, is it reasonably possible to take any specific vulnerability which has been patched but develop a gadget chain to enable it?

Eg, let's say you have a vulnerability X -> leads to Y (say, RCE).

If you could find a chain of gadgets that lead to X (say X1 -> X2 -> X) than you therefore have X1 -> X2 -> X -> Y

And for fun, let's say X2 isn't available, is it reasonable to try to build a chain that does something like XA2 -> XB2 -> XC2 -> X2

And therefore your path would be X1 -> XA2 -> XB2 -> XC2 -> X2 -> X -> Y?

Is this a reasonable way to look at this problem?

The reason I ask is that we build systems where we think we are safe because X isn't immediately a risk. Or even because X1 -> X2 -> X are all patched properly, when in fact if it's possible to decompose any vulnerability into a chain of gadgets, than we are always at risk and therefore most of our security will become the difficulty in getting past security boundaries (escaping a VM, a container, etc).

Given the number of statics in java and java 3rd party libraries, it seems to me that it could be vulnerable to a very large class of gadget chains. In other words, you don't have to craft an attack in just one request, but can do it via a series of requests.

Is this analysis correct?

Improve this question

1 Answer 1

Reset to default
1

However, let's say your json deserializaer (or whatever) is securely configured. Is it possible to create gadget chains which re-configure jackson at runtime to be insecurely configured?

The presumption in your question here is that the vulnerability in Jackson (or whatever) would be merely a matter of poor configuration. Usually, such vulnerabilities are not the result of configuration, but because of code that does the wrong thing. Typically that involves patching the code so it never does the wrong thing.

When we keep that in mind, your general question is clearly revealed to be self contradictory:

More generally, is it reasonably possible to take any specific vulnerability which has been patched but develop a gadget chain to enable it?

If the vulnerability can be trivially enabled in some way, then that merely reveals that it wasn’t properly patched to begin with.

Improve this answer
5
  • COnfiguration can happen in code. If you're familiar with deserilization gadgets you'll notice that the ability to generate arbitrary objects has to be turned on. eg. rules.sonarsource.com/java/RSPEC-4544 / enableDefaultTyping "Using unsafe Jackson deserialization configuration is security-sensitive" I certainly don't expect gadget that enables a vulnerability in a securely patched library to be trivial. Not sure where you got that from. It's important to understand the vulnerable library here is the gadget, not jackson itself (for example).
    – Blaze
    Jun 13, 2019 at 3:14
  • The real question here is what is the feasibility of decomposing a complex vulnerability (eg, enabling something like enableDefaultTyping in a 3rd party library) into a set of less complex gadgets that can be chained. An interesting paper - bodden.de/pubs/fbt+16pshape.pdf
    – Blaze
    Jun 13, 2019 at 3:18
  • @Blaze "Gadgets" are typically code that executes the library. If the code that executes the library can execute it to do the wrong thing, then it hasn't been patched properly. If the problem is that configuration is in the gadget code, then someone would have to apply their own patch to the gadget code to change it (which implies you've already been compromised significantly).
    – Joe
    Jun 13, 2019 at 17:00
  • Timely: waratek.com/…
    – Blaze
    Jun 20, 2019 at 2:54
  • Right, a case where the actual vulnerability wasn't patched properly.
    – Joe
    Jun 20, 2019 at 10:12

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .