BradSwain

4 ms·

1.
by BradSwain 2y ago
> while stack clashing was considered and is a theoretical possibility — denial of service was considered to be the realistic impact. In many contexts, regular process failure is still a vulnerability. And the stack is (usually) tiny com
2.
by BradSwain 2y ago
> Unixes give us that. You have to fork the computation to have it contained in its own process Is forking a new process on each call to a recursive function practical?
3.
by BradSwain 2y ago
> Outdated programming practices are. What is the outdated programming practice at fault here?
4.
by BradSwain 2y ago
I agree. I use the word dangerous to mean there are risks that need to be considered, not that recursion should never be used under any circumstances. In the general case though, recursion can be tricky to think through, the stack is small,
5.
by BradSwain 2y ago
> Any recursive function can be transformed into a tail recursive form, exchanging stack allocation for heap allocation. And any tail recursive program can be transformed into a loop (a trampoline) A computer can chug through millions of
6.
by BradSwain 2y ago
> On modern "hosted" OSes, there are safeguards about stack overflows, which will quickly kill your process. There are lots of contexts where a processing being killed is bad. Sending a deeply nested JSON object as part of a re
7.
by BradSwain 2y ago
This is a neat bug! A colleague and I spent some time last year looking for DoS vulnerabilities caused by recursing on user input [1]. TL;DR: With CodeQL and some manual review, we found several issues resulting in two assigned CVEs, a rust
8.
by BradSwain 2y ago
This is a good point, but recursion and iteration have very different security implications in practice. Iterative functions are much harder to exploit. It doesn't take many stack frames to overflow the stack. Java only handles ~10k fr