(Java) How taint tracking feature reach the internal call of readObject?

[flowiri]

I'm trying to write codeql queries for the CVE-2021-43297 (unsafe toString call lead to deserialization of malicious object). The source of this is the InputStream input parameter of decode method at DecodeableRpcInvocation class. And the sink is obviously the implicit toString call.

I found that the taint tracking flow cannot get to the qualifier of readObject method (at readObject method of Hessian2ObjectInput class. I firstly think that there is barrier, so I using DataFlow to workaround with built-in taint tracking step features, but it still doesn't work. However, when I comment out the predicate defaultAdditionalTaintStep, the queries found the path from source to the qualifier as expected.

One more issue is that it works only with readObject method, but not readUTF method. I can't figure out what code snippet controls it.

I can't understand how that behavior happens! The defaultAdditionalTaintStep predicate is just an OR logic, it could not be a condition that cause fails in the query.

So, how does this happen this way? And is there anyway that allow taint tracking to reach the qualifier of the sink as expected

Link of query and database I used: https://drive.google.com/drive/folders/1ENs1isluvvlmjdpypjfrrxgdRSv6L2sJ?usp=sharing

[smowton]

I'm afraid you're falling afoul of a somewhat-obscure dataflow feature called the field-flow branch limit (https://codeql.github.com/docs/writing-codeql-queries/debugging-data-flow-queries-using-partial-flow/#fieldflowbranchlimit)

In brief, in some situations where the number of possible flows out from a particular node would be excessively large, all flow from that node is discarded and the result can be paradoxical: by adding more possible flow steps, some branching can exceed this limit and so the number of paths found actually falls.

By experimenting with your query, I found that override int fieldFlowBranchLimit() { result = 11 } (default is 2) is the lowest value that produces a result on the database you gave, and override int fieldFlowBranchLimit() { result = 15 } takes an intolerably long time to evaluate.

[flowiri]

Thanks. I would like to inspect more about this feature to fully understand it.

One more thing, I would like to push the taint tracking flow to implicit toString call of obj object. I update the isSink predicate to

implicitToStringCall(sink.asExpr()) and 
sink.asExpr().getCompilationUnit().getName() = "Hessian2Input" and
sink.asExpr().toString() = "obj"

I tried to track the partial flow it can only reach the this <.method> node instead of go into the obj object. I also try override int explorationLimit() { result = 3} and keep override int fieldFlowBranchLimit() { result = 11 } but no lucks.

Is there anyway I could do to make the taint tracking flow goes into the obj object?

In order run the new query with the new isSink predicate, I import semmle.code.java.StringFormat.

Thanks in advance!

[smowton]

It looks like the problem is your source -- in the context input.readObject(), you're tainting input, i.e. the HessianInput itself, not the result of readObject. Then the path you show goes:

• input is tainted,
• Therefore on entering HessianInput.readObject, this is tainted
• ...which calls readInt, which calls expect, with this still tainted
• But the return value of readObject(), stored to obj, is not tainted, and so neither is the read from obj.

If you want instead to taint the result of readObject(), then you should use a source like exists(MethodAccess ma | ma = source.asExpr() | ... check that ma is a call to an interesting method here ...)