[HN Gopher] Recursion kills: The story behind CVE-2024-8176 in l...
       ___________________________________________________________________
        
       Recursion kills: The story behind CVE-2024-8176 in libexpat
        
       Author : spyc
       Score  : 28 points
       Date   : 2025-03-13 22:05 UTC (54 minutes ago)
        
 (HTM) web link (blog.hartwork.org)
 (TXT) w3m dump (blog.hartwork.org)
        
       | hughw wrote:
       | _Please leave recursion to math and keep it out of (in particular
       | C) software: it kills and will kill again._
       | 
       | Is the whole (tail-recursion optimized) Lisp language family
       | subject to DOS? Just check that you terminate at some point,
       | right? "Recursion kills" is just too broad and not helpful.
        
         | Etheryte wrote:
         | The whole point of this CVE is what do you do when the input
         | you're parsing is so large that you run out of space before you
         | can terminate. Tail recursion helps in the sense that the issue
         | will happen later, but it isn't a fix when we're talking about
         | arbitrary data like an XML parser.
        
         | spyc wrote:
         | The point of termination is beyond stack overflow here, that's
         | the problem. And unlike heap, stack does not tell you gently
         | that it's running out.
        
       | baggy_trough wrote:
       | I wonder what would be wrong with changing the recursive function
       | to take a depth and then bailing out if the depth is too big.
        
         | maxbond wrote:
         | You can think of this as having two base cases, your normal
         | success case and an error case. You could use metaprogramming
         | to do this semi-automatically, like a decorator that took a
         | maximum depth and checked it before calling your inner
         | function.
        
         | fpoling wrote:
         | Depth is easy to miss when the parser calls a lot of functions
         | that call each other and that have vastly different stack
         | usage.
         | 
         | A more reliable check is to compare an address of a thing on
         | the stack at api boundary with the current address of things on
         | the stack. SpiderMonkey, the JS engine used something like that
         | in past to stop run-away recursion or at least to switch to
         | slower algorithms with bounded stack usage.
        
       | mightybyte wrote:
       | I would argue that the title is misleading and overly alarmist
       | here. This particular bug may have involved recursion and a stack
       | overflow, but that's like saying "malloc kills" in the title of
       | an article about a heap overflow bug. The existence of stack
       | overflow bugs does not imply that recursion is bad any more than
       | the existence of heap overflow bugs implies that malloc is bad.
       | Recursion and malloc are tools that both have pretty well
       | understood resource limitations, and one must take those
       | limitations into account when employing those tools.
        
         | timewizard wrote:
         | Using recursive techniques to parse potentially hostile inputs
         | kills.
        
       ___________________________________________________________________
       (page generated 2025-03-13 23:00 UTC)