-
Notifications
You must be signed in to change notification settings - Fork 545
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
Stack Comsumption Problem Caused By the mark_beginning_as_normal Function Making Recursive Calls to Itself #414
Comments
We can directly look at the snippet code of nfa.c to see if it is possible to have infinite recursion. Intuitively, in some cases, function mark_beginning_as_normal shows the behavior of recursive calls.
This is simply running out of stack space. You can make the number of recursions go up by 11,000 or so by dynamically allocating variables instead of using stack space, but at the end of the day, you can work around this (for this test case) by doing:
Of course, a much larger (deeper) YAML file will still make it crash. You can thus, make it happen far faster by doing:
The crash does not seem to happen due to any buffer overflows or memory corruption; it's simply the kernel saying "you're out of stack space, please die". One simple way to avoid the crash itself is to do a depth-check of the tree and compare it to some value related to the stack size returned and produce an error if the values are way out of whack. A more complicated solution would involve removing recursion, which looks like it would not be a trivial fix. |
https://security-tracker.debian.org/tracker/CVE-2019-6293 NixOS/nixpkgs#55386 (comment) "But this bug does not cause stack overflows in the generated code. The function and file referred to in the bug (mark_beginning_as_normal in nfa.c) are part of the flex code generator, not part of the generated code. If flex crashes before generating any code, that can hardly be a vulnerability. If flex does not crash, the generated code is fine (or perhaps subject to other unreported bugs, who knows, but the NFA has been generated correctly)." Upstream has chosen to not provide a fix westes/flex#414 Signed-off-by: Matthew Weber <[email protected]> [[email protected]: use actual upstream URL] Signed-off-by: Yann E. MORIN <[email protected]>
https://security-tracker.debian.org/tracker/CVE-2019-6293 NixOS/nixpkgs#55386 (comment) "But this bug does not cause stack overflows in the generated code. The function and file referred to in the bug (mark_beginning_as_normal in nfa.c) are part of the flex code generator, not part of the generated code. If flex crashes before generating any code, that can hardly be a vulnerability. If flex does not crash, the generated code is fine (or perhaps subject to other unreported bugs, who knows, but the NFA has been generated correctly)." Upstream has chosen to not provide a fix westes/flex#414 Signed-off-by: Matthew Weber <[email protected]> [[email protected]: use actual upstream URL] Signed-off-by: Yann E. MORIN <[email protected]> (cherry picked from commit 120d124) Signed-off-by: Peter Korsgaard <[email protected]>
CVE is effectively disputed - yes there is stack exhaustion but no bug and it is building the parser, not running it, effectively similar to a compiler ICE. Upstream no plans to address and there is no security issue. westes/flex#414 Signed-off-by: Richard Purdie <[email protected]>
CVE is effectively disputed - yes there is stack exhaustion but no bug and it is building the parser, not running it, effectively similar to a compiler ICE. Upstream no plans to address and there is no security issue. westes/flex#414 (From OE-Core rev: 0cae5d7a24bedf6784781b62cbb3795a44bab4d1) Signed-off-by: Richard Purdie <[email protected]>
CVE is effectively disputed - yes there is stack exhaustion but no bug and it is building the parser, not running it, effectively similar to a compiler ICE. Upstream no plans to address and there is no security issue. westes/flex#414 (From OE-Core rev: 0cae5d7a24bedf6784781b62cbb3795a44bab4d1) Signed-off-by: Richard Purdie <[email protected]>
CVE is effectively disputed - yes there is stack exhaustion but no bug and it is building the parser, not running it, effectively similar to a compiler ICE. Upstream no plans to address and there is no security issue. westes/flex#414 (From OE-Core rev: 0cae5d7a24bedf6784781b62cbb3795a44bab4d1) Signed-off-by: Richard Purdie <[email protected]>
CVE is effectively disputed - yes there is stack exhaustion but no bug and it is building the parser, not running it, effectively similar to a compiler ICE. Upstream no plans to address and there is no security issue. westes/flex#414 Signed-off-by: Richard Purdie <[email protected]> (cherry picked from commit 0cae5d7) Signed-off-by: Steve Sakoman <[email protected]>
CVE is effectively disputed - yes there is stack exhaustion but no bug and it is building the parser, not running it, effectively similar to a compiler ICE. Upstream no plans to address and there is no security issue. westes/flex#414 (From OE-Core rev: b939b005b06be58a276d565f755ee2d8f3e5dfc1) Signed-off-by: Richard Purdie <[email protected]> (cherry picked from commit 0cae5d7a24bedf6784781b62cbb3795a44bab4d1) Signed-off-by: Steve Sakoman <[email protected]> Signed-off-by: Richard Purdie <[email protected]>
Source: poky MR: 112421 Type: Integration Disposition: Merged from poky ChangeID: 6aa55dd279b14b34f334b8d70f7046720fc6764d Description: CVE is effectively disputed - yes there is stack exhaustion but no bug and it is building the parser, not running it, effectively similar to a compiler ICE. Upstream no plans to address and there is no security issue. westes/flex#414 (From OE-Core rev: b939b005b06be58a276d565f755ee2d8f3e5dfc1) Signed-off-by: Richard Purdie <[email protected]> (cherry picked from commit 0cae5d7a24bedf6784781b62cbb3795a44bab4d1) Signed-off-by: Steve Sakoman <[email protected]> Signed-off-by: Richard Purdie <[email protected]> Signed-off-by: Jeremy A. Puhlman <[email protected]>
CVE is effectively disputed - yes there is stack exhaustion but no bug and it is building the parser, not running it, effectively similar to a compiler ICE. Upstream no plans to address and there is no security issue. westes/flex#414 Signed-off-by: Richard Purdie <[email protected]> (cherry picked from commit 0cae5d7) Signed-off-by: Anuj Mittal <[email protected]>
CVE is effectively disputed - yes there is stack exhaustion but no bug and it is building the parser, not running it, effectively similar to a compiler ICE. Upstream no plans to address and there is no security issue. westes/flex#414 (From OE-Core rev: e2de2e5e977d84dab6cb1461800d4c29436da5c9) Signed-off-by: Richard Purdie <[email protected]> (cherry picked from commit 0cae5d7a24bedf6784781b62cbb3795a44bab4d1) Signed-off-by: Anuj Mittal <[email protected]> Signed-off-by: Richard Purdie <[email protected]>
Does anyone care about this? |
Short answer: nfa.c is working as intended. Looks like the failing input comes from a fuzzer. It consists of around 16KB of *s in a row, plus some other junk. The crash occurs in flex itself, not the scanner produced by flex. The protection against exploit is to not run flex setuid. This is already the default. I'm not very concerned that we see stack exhaustion when someone feeds exceptionally long garbage input to flex. Detecting that before processing would require solving the halting problem so we just have to begin. If there's a cleaner way to fail, I'm glad to hear it of course. Also, if there's a smaller, more realistic POC that would be something to consider. |
CVE is effectively disputed - yes there is stack exhaustion but no bug and it is building the parser, not running it, effectively similar to a compiler ICE. Upstream no plans to address and there is no security issue. westes/flex#414 (From OE-Core rev: 0cae5d7a24bedf6784781b62cbb3795a44bab4d1) Signed-off-by: Richard Purdie <[email protected]>
CVE is effectively disputed - yes there is stack exhaustion but no bug and it is building the parser, not running it, effectively similar to a compiler ICE. Upstream no plans to address and there is no security issue. westes/flex#414 (From OE-Core rev: 0cae5d7a24bedf6784781b62cbb3795a44bab4d1) Signed-off-by: Richard Purdie <[email protected]>
Hi there,
An issue was discovered in function mark_beginning_as_normal in nfa.c, as distributed in flex 2.6.4. There is a stack exhaustion problem caused by the in mark_beginning_as_normal function making recursive calls to itself in certain scenarios involving lots of '*' characters.
Here is the POC file. Please use the “./flex $POC” to reproduce the bug.
POC.zip
Command:“./flex $POC”
The ASAN dumps the stack trace as follows:
The text was updated successfully, but these errors were encountered: