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

Add detection for Recursion in Java #14

Open
wants to merge 10 commits into
base: main
Choose a base branch
from
Open

Conversation

DarkaMaul
Copy link
Contributor

To prepare for the blogpost publication.

Copy link
Member

@mschwager mschwager left a 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/)
Copy link
Member

Choose a reason for hiding this comment

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

TODO

@GrosQuildu
Copy link
Contributor

GrosQuildu commented Nov 15, 2024

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 level1->level2->level3 now we show 3 results).

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>
Copy link
Contributor

Choose a reason for hiding this comment

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

TODO

java/src/security/Recursion/Recursion.ql Outdated Show resolved Hide resolved
return directRecursiveDepth(depth - 1);
}

// todook: recursion is limited
Copy link
Contributor Author

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 :(

Copy link
Contributor

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

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.

3 participants