From URL: "re2c is affected by an infinite loop. It was initially discovered by Sergei Trofimovich (slyfox) and reported by me privately to upstream. The upstream reference is at: https://github.com/skvadrik/re2c/issues/219 There is no CVE assigned. Here is the additional upstream comment: I fixed enough recursive functions to make the ASAN-instrumented re2c pass on this file (but that doesn't fully fix #219, as some other recursive functions still need rewriting, work in progress). This is the list of fixes: fd634998f813340768c333cdad638498602856e5 Rewrite recursion into iteration (Tarjan's SCC algorithm and YYFILL states). 637d4e468835690eac102aba83535dfd26afbbdb Rewrite recursion into iteration (paths for -Wundefined-control-flow). e3e43bcbb746dd6692f2d60ed1fa2e26c8cbe987 Rewrite recursion into iteration (skeleton max path length computation). f39b522cd40d04e80b77db926ce2d7d766954852 Rewrite recursion into iteration (insertion of negative tags in RE). They will appear in the next release, re2c-2.0."
The bug you linked is not an infinite loop.
(In reply to Sergei Trofimovich from comment #1) > The bug you linked is not an infinite loop. Yep, I quoted from the ML and didn't think about it.
Most programs will crash given small enough program stack. Don't think that it matters if the usage is bounded or not in this specific case. Many programs have stack (and heap) usage as a function of it's input. Especially the ones that traverse the in-memory trees, like gcc or re2c. Why in this case we care about it as a vulnerability?
(In reply to Sam James from comment #0) > From URL: > "re2c is affected by an infinite loop. > > It was initially discovered by Sergei Trofimovich (slyfox) and reported by > me > privately to upstream. > The upstream reference is at: https://github.com/skvadrik/re2c/issues/219 > There is no CVE assigned. > > Here is the additional upstream comment: > > I fixed enough recursive functions to make the ASAN-instrumented re2c > pass on this file (but that doesn't fully fix #219, as some other > recursive functions still need rewriting, work in progress). > This is the list of fixes: > fd634998f813340768c333cdad638498602856e5 Rewrite recursion into iteration > (Tarjan's SCC algorithm and YYFILL states). > 637d4e468835690eac102aba83535dfd26afbbdb Rewrite recursion into iteration > (paths for -Wundefined-control-flow). > e3e43bcbb746dd6692f2d60ed1fa2e26c8cbe987 Rewrite recursion into iteration > (skeleton max path length computation). > f39b522cd40d04e80b77db926ce2d7d766954852 Rewrite recursion into iteration > (insertion of negative tags in RE). > They will appear in the next release, re2c-2.0." All of these commits have been released upstream for some time, are we able to move forward with this bug?
Restating the question from #comment3: was it ever a bug?
(In reply to Sergei Trofimovich from comment #5) > Restating the question from #comment3: was it ever a bug? Upstream seems to think so, so we'll proceed here based on those fixes, which have been included in 2.0.0 and tree is clean since October: commit 1833d6912b2b2d5c83e43ff17ae99c2bbc1d135a Author: Sergei Trofimovich <slyfox@gentoo.org> Date: Sat Oct 10 09:24:18 2020 +0100 dev-util/re2c: drop old Package-Manager: Portage-3.0.8, Repoman-3.0.1 Signed-off-by: Sergei Trofimovich <slyfox@gentoo.org>
(In reply to John Helmert III (ajak) from comment #6) > (In reply to Sergei Trofimovich from comment #5) > > Restating the question from #comment3: was it ever a bug? > > Upstream seems to think so, so we'll proceed here based on those fixes, > which have been included in 2.0.0 and tree is clean since October: > > commit 1833d6912b2b2d5c83e43ff17ae99c2bbc1d135a > Author: Sergei Trofimovich <slyfox@gentoo.org> > Date: Sat Oct 10 09:24:18 2020 +0100 > > dev-util/re2c: drop old > > Package-Manager: Portage-3.0.8, Repoman-3.0.1 > Signed-off-by: Sergei Trofimovich <slyfox@gentoo.org> delete mode 100644 dev-util/re2c/re2c-1.3-r1.ebuild
(In reply to Sergei Trofimovich from comment #5) > Restating the question from #comment3: was it ever a bug? If an attacker is able to crash a program it's per definition a DoS bug. If an attacker must convince a user to run crafted input through a program to cause the crash it's per definition an user-assisted DoS bug. Of course the impact is questionable, especially in this specific case. But think about a crafted archive file which would be able to crash unzip, unrar.. in context of a mail server which is scanning incoming files: Depending on how badly a crash would affect the system (think about zip bombs which could exhaust system's memory which would trigger OOM killer), a user-assisted DoS bug can become a problem. In case of dev-util/re2c, the package is a dependency of dev-util/ninja which is present on most Gentoo systems (A) and therefore per definition (https://www.gentoo.org/support/security/vulnerability-treatment-policy.html) we have to create a GLSA.
(In reply to Thomas Deutschmann from comment #8) > (In reply to Sergei Trofimovich from comment #5) > > Restating the question from #comment3: was it ever a bug? > > If an attacker is able to crash a program it's per definition a DoS bug. > If an attacker must convince a user to run crafted input through a program > to cause the crash it's per definition an user-assisted DoS bug. > Of course the impact is questionable, especially in this specific case. > > But think about a crafted archive file which would be able to crash unzip, > unrar.. in context of a mail server which is scanning incoming files: > Depending on how badly a crash would affect the system (think about zip > bombs which could exhaust system's memory which would trigger OOM killer), a > user-assisted DoS bug can become a problem. I agree that program that handle untrusted input have to have very well defined behaviour on any inputs. Is Gentoo's security model turns re2c (and gcc) into such a program? If it does I'd like to understand how it does it. > In case of dev-util/re2c, the package is a dependency of dev-util/ninja > which is present on most Gentoo systems (A) and therefore per definition > (https://www.gentoo.org/support/security/vulnerability-treatment-policy. > html) we have to create a GLSA. re2c (similar to gcc but in a scaled down version) is a code generator. It's normally used only at package (like ninja or php) build time by producing .c files out of .re files. In case of this bug "best" effect you could get is not to get .c file back by crashing re2c. That would require untrusted .re input. The example I could understand where it matters is if one could make a webapp that calls re2c (or gcc) directly on untrusted input and server data back to user. That would probably allow data exfiltration with use of "#include /etc/passwd" directive equivalents. But we are not (I hope!) treating it as an RCE in re2c (or gcc). Thus I fail to see the model under which stack overflow for re2c specifically is a security bug (or bug at all). I suspect gcc is very easy to get out of it's stack (or heap, or get into O(N^2) behaviour) when fed arbitrary source files. Is every gcc stack overflow, ICE, hangup and slowdown now a CVE worth tracking and mitigating in Gentoo?
(In reply to Thomas Deutschmann (RETIRED) from comment #8) > (In reply to Sergei Trofimovich from comment #5) > > Restating the question from #comment3: was it ever a bug? > > If an attacker is able to crash a program it's per definition a DoS bug. > If an attacker must convince a user to run crafted input through a program > to cause the crash it's per definition an user-assisted DoS bug. > > Of course the impact is questionable, especially in this specific case. > > But think about a crafted archive file which would be able to crash unzip, > unrar.. in context of a mail server which is scanning incoming files: > Depending on how badly a crash would affect the system (think about zip > bombs which could exhaust system's memory which would trigger OOM killer), a > user-assisted DoS bug can become a problem. > > In case of dev-util/re2c, the package is a dependency of dev-util/ninja > which is present on most Gentoo systems (A) and therefore per definition > (https://www.gentoo.org/support/security/vulnerability-treatment-policy. > html) https://doodlecricket.io we have to create a GLSA. I concur that a program handling untrusted input needs to have extremely clear behavior for all inputs. Is gcc and re2c transformed into such a program by Gentoo's security model? If so, please explain how it accomplishes it.
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/data/glsa.git/commit/?id=35ffd13fdba48bf63cbd9ac9cf065e60295c678c commit 35ffd13fdba48bf63cbd9ac9cf065e60295c678c Author: GLSAMaker <glsamaker@gentoo.org> AuthorDate: 2024-08-09 07:09:13 +0000 Commit: Hans de Graaff <graaff@gentoo.org> CommitDate: 2024-08-09 07:09:23 +0000 [ GLSA 202408-16 ] re2c: Denial of Service Bug: https://bugs.gentoo.org/719872 Signed-off-by: GLSAMaker <glsamaker@gentoo.org> Signed-off-by: Hans de Graaff <graaff@gentoo.org> glsa-202408-16.xml | 42 ++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 42 insertions(+)
