-
Notifications
You must be signed in to change notification settings - Fork 3
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
Add detection for Recursion in Java #14
base: main
Are you sure you want to change the base?
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Overall, this LGTM. I added @GrosQuildu for review too.
This isn't a blocker, but I wonder if we can generalize the RecursiveCallOrderN
functionality. It'd be nice to be able to specify arbitrary depth, and have the default value be 4. I think that would end up creating a cleaner query too, but probably requires some more advanced CodeQL functionality. Anyway, I was just curious if you considered this.
Also, have you done any MVRA runs to check for false positives and such?
|
||
|
||
## References | ||
* Trail Of Bits Blog: [Low-effort denial of service with recursion](https://blog.trailofbits.com/2024/05/16/TODO/) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
TODO
I added more tests in one commit (please keep them). In the second one, I proposed a much-simplified query that finds any recursive loops. From MVRA the query is speedy enough, but returns a lot of false positives. Would be great to limit FPs before publication with at least this heuristic: do not report if there is a depth/level argument (any number) that is changed for any call in the recursion call path. Moreover, would be nice to print the offensive method and all methods in the call-path, so debugging is easier. We would need to use path-query instead of the problem one. Then we could also trim results by showing only one method from a cycle (e.g., for Added these TODOs in query code. Lastly, finding unbounded recursive paths with high precision is probably a hard problem. Would be nice to figure additional heuristics to limit false positives. Probably the "call depth depends on user-controlled input" is the useful one, and we can model it in codeql relatively easily. |
</example> | ||
<references> | ||
<li> | ||
Trail Of Bits Blog: <a href="https://blog.trailofbits.com/2024/05/16/TODO/">Low-effort denial of service with recursion</a> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
TODO
f3dbae7
to
06cae62
Compare
return directRecursiveDepth(depth - 1); | ||
} | ||
|
||
// todook: recursion is limited |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I could not make this one not be flagged :(
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
May need a local data flow; but that's not a very often pattern I guess
To prepare for the blogpost publication.