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

fixes taint propagation for unmodeled subroutines #1147

Conversation

ivg
Copy link
Member

@ivg ivg commented Jun 23, 2020

When a subroutine is unmodeled and we introduce taint directly
in the call-return method the taint will be attached to a
temporary value and never be really used anywhere.

The reason for that is that we attach the taint to a value stored in
the right-hand side of the argument term, but the right-hand side
could be an arbitrary expression, e.g., RAX.RDI or low:32[RAX],
etc. Therefore the value stored in the left-hand side of the argument
term is the result of the evaluation of this expression and is never used
afterward, so instead of tainting RAX and RDI which are really
used by the lifted code, we lift the freshly created RAX.RDI value.

This is a general problem and this PR doesn't provide the general
solution but enables taint propagation for a specific case when the
right-hand side expression is a simple variable. It used to work
before, because we were ignoring that our arg_terms inserted by the
api pass are ill-typed for architectures where the size of integer
data type is smaller than the size of the machine register. In BAP
2.1.0 we relaxed the interpreter and let it grok ill-typed expressions
by adding coercions, which jumped in our case, since they created a
new coerced value.

This small fix restores the status quo for taint analysis that was
before 2.1.0, but the right solution should be implemented, as it
still doesn't work for more complex expressions.

When a subroutine is unmodeled and we introduce taint directly
in the `call-return` method the taint will be attached to a
temporary value and never be really used anywhere.

The reason for that is that we attach the taint to a value stored in
the right-hand side of the argument term, but the right-hand side
could be an arbitrary expression, e.g., `RAX.RDI` or `low:32[RAX]`,
etc. Therefore the value stored in the left-hand side of the argument
term is the result of evaluation of this expression and is never used
afterwards, so instead of tainting `RAX` and `RDI` which are really
used by the lifted code, we lift the freshly created `RAX.RDI` value.

This is a general problem and this PR doesn't provide the general
solution but enables taint propagation for a specific case when the
right-hand side expression is a simple variable. It used to work
before, because we were ignoring that our arg_terms inserted by the
api pass are ill-typed for architectures where the size of integer
data type is smaller than the size of the machine register. In BAP
2.1.0 we relaxed the interpreter and let it grok ill-typed expressions
by adding corecions, which jumped in our case, since they created a
new coerced value.

This small fix restores the status quo for taint analysis that was
before 2.1.0, but the right solution should be implemented, as it
still doesn't work for more complex expressions.
@ivg ivg merged commit 78868cb into BinaryAnalysisPlatform:master Jun 23, 2020
@ivg ivg deleted the fix-taint-propagation-for-unmodeled-subroutines branch December 1, 2021 19:13
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

1 participant