> 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…
> 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?
> Outdated programming practices are. What is the outdated programming practice at fault here?
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…
> 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…
> 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…
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…
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…
> 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…
> 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?
> Outdated programming practices are. What is the outdated programming practice at fault here?
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…
> 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…
> 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…
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…
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…