os_xml _ReadElem() - Uncontrolled recursion vulnerability leading to DoS (SIGSEGV) #1953
Comments
|
CVE-2021-28040 was assigned to this issue. |
|
We've solved this issue in our fork by limiting the number of times |
|
Hello all, Thank you all for your work! Does anyone knows if a fix is planned ? |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
os_xml _ReadElem() - Uncontrolled recursion vulnerability
INTRODUCTION
An Uncontrolled Recursion vulnerability has been identified in the
os_xmlXML parsing library used by OSSEC.Through the
os_xml/examples/test.ccode, a flaw has been identified inos_xml.cthat allows non-defined recursion cycles,thus finally trying to access non-mapped memory once the stack end has been reached.
The payload consists on a number of
<>which will trigger the recursion and finally ending it with<\n.REPRODUCE
To reproduce this vulnerability, compile the
examples/test.cand open the payload file with it.If we compile
examples/test.cwith ASAN (AddressSanatizer), this is the output we are given:As we can see an unlimited number of recursion calls can be performed, ending on a SIGSEGV (Segmentation fault).
Attention!: If a SIGSEGV is not triggered, try adding more
<>in the payload. The segmentation fault error is because we reach the end of the stack, so it depends on the offset until the end of it, which may differ in your situation.ANALYSIS
There exists a non limited recursion in the
_ReadElem()function:If we debug it after specifying the crash file as argument:
A SIGSEGV (Segmentation fault) happens when trying to access invalid memory as the
rspregister contains an address that is not mapped.IMPACT
The most common issue with this type of vulnerability is a Denial of Service (DoS) once a crash has been triggered as demonstrated above with the crash PoC.
SOLUTION
The best solution to this vulnerability is implementing a code that controls the number of allowed recursions, or redesigning the methodology to loop over the XML tags using a
whileorforloop instead of recursing if the number of needed iterations is huge, resulting in a Stack exhaustion.The DoS is performed due to the creation of a new frame in the stack for each new function being called. Creation of a big amount of frames results after a lot of iterations in consuming up the available stack memory, and once reached non-mapped memory a segmentation fault interruption will happen.
An important factor that decreases a lot the needed iterations to finally trigger the bug is the existence of three big stack buffers in the recursive function. Another useful change would be using dynamic memory with
malloc()orcalloc()when big amount of space is needed, also it can be reused instead of creating a chunk or stack buffer for each function call.The text was updated successfully, but these errors were encountered: