Skip to content

C++ Improvements to TaintedAllocationSize.ql #3241

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

Merged
merged 5 commits into from
Apr 15, 2020
Merged

Conversation

geoffw0
Copy link
Contributor

@geoffw0 geoffw0 commented Apr 9, 2020

Improvements to TaintedAllocationSize.ql:

  • removed the results on tainted x * sizeof(y) expressions (a clever trick that worked remarkably well, but we have better models and taint flow so we no longer need it; just leads to duplicate and less clear results now)
  • produce better locations on calls to malloc wrappers (i.e. at the place where the wrapper's called rather than inside it)

This was supposed to be in 1.24 as there are multiple user requests for improvements, however I think it's too complex to rush in that quickly now. 1.24 already contains #3062 and improvements to models and taint, so hopefully progress will be apparent.

Before this is merged I need to make a PR for the code repo (some tests are affected), add more tests of the edge cases, and most likely move the change note from 1.24 to 1.25. But I'd like to solicit feedback and iterate before I get caught up in the submodule update war.

@geoffw0 geoffw0 added C++ WIP This is a work-in-progress, do not merge yet! labels Apr 9, 2020
@geoffw0 geoffw0 requested a review from a team as a code owner April 9, 2020 17:06
Copy link
Contributor

@MathiasVP MathiasVP left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I like the changes so far! I haven't looked at it in detail yet, but I did have one question.

*/
predicate allocExprOrIndirect(Expr e, Expr size, Expr mid, AllocationExpr alloc) {
isAllocationExpr(alloc) and
size = alloc.getSizeExpr() and
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can we reduce the false postive rate even more by excluding the allocations with a size we can prove will never overflow (e.g., with SimpleRangeAnalysis.qll?)

I tried doing a (very naive) comparison test between this new version of the query with and without the use of range analysis, and it does exclude some results: https://lgtm.com/query/7744692820054815595/

I haven't verified whether those results are meaningful yet, though.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for this suggestion, I'll come back to it after the milestone.

) {
isUserInput(source, taintCause) and
exists(Expr tainted |
taintedChild(e, tainted) and
allocExprOrIndirectRoot(alloc, tainted, _) and
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think this has false negatives if there's multiple layers of wrappers that are used by non-library code - e.g. if there's a my_calloc that calls my_malloc that calls malloc, tainted sizes in direct invocations of my_malloc could be missed.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This commit has been removed from the PR, but I'll come back to it at some point. I think you're right, and it certainly deserves a test case.

@jbj
Copy link
Contributor

jbj commented Apr 14, 2020

I'd like to get this query fixed in 1.24, but I agree that this PR is too risky for 1.24. If you drop 90e77d9, I'd be fine with merging the rest. I think it satisfies the hotfix criteria.

Since we now have path explanations for this query, the lack of allocation wrapper support is surely not as bad as it used to be. In any case, it's not a regression since 1.23, right?

@geoffw0
Copy link
Contributor Author

geoffw0 commented Apr 14, 2020

If you drop 90e77d9, I'd be fine with merging the rest. I think it satisfies the hotfix criteria.

Done (via a rebase), and updated the change note.

Since we now have path explanations for this query, the lack of allocation wrapper support is surely not as bad as it used to be. In any case, it's not a regression since 1.23, right?

I agree, with the slight qualification that I haven't seen how clearly the path explanations are actually presented in LGTM right now.

@jbj jbj changed the base branch from master to rc/1.24 April 14, 2020 13:10
@jbj jbj added this to the 1.24 milestone Apr 14, 2020
jbj
jbj previously approved these changes Apr 14, 2020
Copy link
Contributor

@jbj jbj left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM now. I've retargeted this PR to rc/1.24.

@geoffw0 geoffw0 removed the WIP This is a work-in-progress, do not merge yet! label Apr 14, 2020
@geoffw0 geoffw0 requested review from a team as code owners April 15, 2020 08:28
@geoffw0 geoffw0 requested review from tausbn and removed request for a team April 15, 2020 08:29
@geoffw0
Copy link
Contributor Author

geoffw0 commented Apr 15, 2020

Added the corresponding test changes in the code repo: https://git.semmle.com/Semmle/code/pull/36694 (these two PRs should be merged at the same time).

@tausbn tausbn removed request for a team and tausbn April 15, 2020 09:14
@geoffw0 geoffw0 added the depends on internal PR This PR should only be merged in sync with an internal Semmle PR label Apr 15, 2020
@jbj jbj merged commit 6eba338 into github:rc/1.24 Apr 15, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
C++ depends on internal PR This PR should only be merged in sync with an internal Semmle PR
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants