Java: catch delayed unsafe deserialization #8766
Open
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This pull request was slpit from #8501 as suggested by @smowton.
Deserialization can sometimes be implemented in two steps. An untrusted serialized object can be stored in a field but actual deserialization happens only when the object is necessary. CVE-2016-6194 in RabbitMQ is an example of such scenario (GitHub issue). Untrusted data that comes from a response is stored in
RMQObjectMessage.buf
field. Then, deserialization happens whengetObject()
method is called. Currently,java/unsafe-deserialization
query doesn't catch this.I'd like to propose a new experimental query that contains a flow step that propagates taint from a byte array to a field.
The new query detects CVE-2016-6194. Let me know what you think.
This PR is related to github/securitylab#556