Hi all, > Le 30 août 2020 à 16:57, Akim Demaille <[email protected]> a écrit : > > Hi Paul, > > Rici Lake drew my attention to something new: people create CVEs about Bison: > > - https://nvd.nist.gov/vuln/detail/CVE-2020-14150 > GNU Bison before 3.5.4 allows attackers to cause a denial of service > (application crash). > > - https://nvd.nist.gov/vuln/detail/CVE-2020-24240 > GNU Bison 3.7 has a use after free (UAF) vulnerability. A local attacker may > execute bison with crafted input file containing a NULL byte, which could > triggers UAF and thus cause system crash. > > In both cases it's about bison itself crashing on carefully crafted junk > (read, found by fuzzing). These CVEs cast aspersion on Bison, possibly > letting users fear that their application is compromised if they use > Bison–which of course is not the case.
I have written to MITRE, asking for the CVEs to be clarified, and they answered favorably: - https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-14150 now reads: GNU Bison before 3.5.4 allows attackers to cause a denial of service (application crash). NOTE: there is a risk only if Bison is used with untrusted input, and an observed bug happens to cause unsafe behavior with a specific compiler/architecture. The bug reports were intended to show that a crash may occur in Bison itself, not that a crash may occur in code that is generated by Bison. - https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-24240 now reads: GNU Bison before 3.7.1 has a use-after-free in _obstack_free in lib/obstack.c (called from gram_lex) when a '\0' byte is encountered. NOTE: there is a risk only if Bison is used with untrusted input, and the observed bug happens to cause unsafe behavior with a specific compiler/architecture. The bug report was intended to show that a crash may occur in Bison itself, not that a crash may occur in code that is generated by Bison. As a matter of fact, I'm quite impressed by the quality of their answer, that they allowed me to forward here. You'll find it below. Thanks to the anonymous person who answered to my request. So I believe that I can indeed tone down the banner in NEWS. I'm pushing what follows into maint (I expect to release 3.7.2 this weekend). Cheers! commit 3da17724ad5a789292dac5187ebb885d6ea4da04 Author: Akim Demaille <[email protected]> Date: Sun Aug 30 16:15:39 2020 +0200 doc: updates * NEWS, TODO: here. diff --git a/NEWS b/NEWS index a5c59f0d..d5a816b4 100644 --- a/NEWS +++ b/NEWS @@ -2,9 +2,24 @@ GNU Bison NEWS * Noteworthy changes in release ?.? (????-??-??) [?] + This release of Bison fixes all known bugs reported for Bison in MITRE's + Common Vulnerabilities and Exposures (CVE) system. These vulnerabilities + are only about bison-the-program itself, not the generated code. + + Although these bugs are typically irrelevant to how Bison is used, they + are worth fixing if only to give users peace of mind. + + There is no known vulnerability in the generated parsers. + ** Bug fixes - Push parsers use YYMALLOC/YYFREE instead of direct calls to malloc/free. + Push parsers always use YYMALLOC/YYFREE (no direct calls to malloc/free). + + Portability issues of the test suite, and of bison itself. + + Some unlikely crashes found by fuzzing have been fixed. This is only + about bison itself, not the generated parsers. + * Noteworthy changes in release 3.7.1 (2020-08-02) [stable] @@ -560,7 +575,8 @@ GNU Bison NEWS \005) with incorrect styling. Fixes for similar issues with unexpectedly short lines (e.g., the file was changed between parsing and diagnosing). - Several unlikely crashes found by fuzzing have been fixed. + Some unlikely crashes found by fuzzing have been fixed. This is only + about bison itself, not the generated parsers. * Noteworthy changes in release 3.5.2 (2020-02-13) [stable] diff --git a/TODO b/TODO index b8b2befb..e9874678 100644 --- a/TODO +++ b/TODO @@ -1,4 +1,12 @@ -* Bison 3.7 +* Soon +** gnulib +Bruno notes: + +> I haven't looked deeply, but it strikes me that gnulib/lib/bitset/array.c +> does not make use of the 'ffsl' function, nor or the 'integer_length_l' +> function. Maybe because in Bison, all bitsets are so dense that it does +> not give a performance advantage? + ** Cex *** Improve gnulib Don't do this (counterexample.c): Début du message réexpédié : De: [email protected] Objet: Rép : [scr951593] Bison and CVE Date: 31 août 2020 à 04:20:53 UTC+2 À: [email protected] Cc: [email protected] -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 > https://stackoverflow.com/questions/63048640/where-can-i-get-a-windows-executable-for-gnu-bison-3-5-4 > https://lists.gnu.org/r/bison-patches/2020-08/msg00028.html > > Bison is a generator: you feed it with a grammar file, it generates a > source file. That CVE is about bison itself: if you feed bison with > crafted invalid input, it will crash. This is *harmless*, much like a > compiler internal error is annoying but harmless: nothing invalid is > generated. In particular, there is no known vulnerabilities in the > generated source files. As visible on Stackoverflow and elsewhere > people are now afraid of Bison pre 3.5.4 because of this CVE, although > they are not concerned at all. So I suggest to reword this CVE as > follows: > >> GNU Bison before 3.5.4 can crash on some invalid input. Generated >> programs are not affected, only the program Bison itself. > > I would advice against accepting such CVEs in the future, they are not > helpful at all. CVE-2020-24240 is another instance of that pattern. > Bison crashes are plain bugs, not CVEs affecting end users. Thank you for contacting us. We will be adding more information to both CVE-2020-14150 and CVE-2020-24240 to indicate that there may be no risk in a typical Bison use case. We completely agree that CVEs should not exist for many types of crashes of command-line tools, desktop applications, and client programs. We don't agree with your premise that "if you feed bison with crafted invalid input, it will crash. This is *harmless*" or with the stackoverflow comment of "you don't let attackers run build tools on your machine. (If they could do that, they would already have exploited a vulnerability.)" or "Building the parser is also safe, because you are not trying to exploit yourselves. The worst that could happen is that bison could crash instead of building a parser, but that's extremely unlikely, and even if it happens, all that happens is that a program has crashed on one of your development machines." Some people create websites that accept a grammar as untrusted input, and provide an output report that describes properties of the grammar. Two examples are: https://smlweb.cpsc.ucalgary.ca/start.html http://mdaines.github.io/grammophone/ They can be useful for students who are beginning to learn about compilers. Note that these websites simply produce reports about a grammar. They don't try to execute any generated code, or execute C code that is embedded in the input. In other words, they are not inherently granting code-execution privileges to website visitors. (We don't know of websites that require the grammar input format used by Bison, and proceed to run "bison -r" on the untrusted input. However, this may be plausible.) If any type of grammar parser has a buffer overflow, and an attacker's web client provides crafted invalid input (with specific long strings), then the attacker can run arbitrary code on the web server. For CVE-2020-14150 and CVE-2020-24240, we didn't have enough information to decide whether arbitrary code execution might be possible in this client/server use case. Certainly, if someone asked for a CVE for a clean crash of Bison (e.g., attempted division by zero) with no possibility of memory corruption, then we would reject the report and not assign a CVE. Similarly, if the Bison ChangeLog has said "Several unlikely crashes found by fuzzing have been fixed. These crashes are NOT accompanied by memory corruption." then we would reject it / not assign a CVE. The problematic CVEs are the ones where both: - we don't know all of the plausible use cases for the software - the report doesn't directly comment on whether memory corruption may occur However, we agree that having few (if any) CVEs for Bison is generally better for most people who rely on CVE. We will try to treat any further reports about Bison with additional suspicion. Thank you for raising this important concern. - -- CVE Assignment Team M/S M300, 202 Burlington Road, Bedford, MA 01730 USA [ A PGP key is available for encrypted communications at http://cve.mitre.org/cve/request_id.html ] -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQIcBAEBCAAGBQJfTF3gAAoJEPNX0OmQPkAI8FcP/A/ITcn3mPo7iSpZBGDFT7VI yO5k+I9ZmK/ULpc9j6BVs8EOxKMsy0D34/WONzul/UbC9AAc+S4PA+v0WedPRsO1 qRLCZt1OieViHQPhO7CY8MOrcUuexHr55i1eMztFuWPzmvPk/RZgNU+r8HanlgXs NcMTpjhiKnkadP9cyONOMR31TWLm5qq6jhD1pYyFumnDc1iicNEt5ktz9nVI5ngA /FJAvhwivFNEnOUXpTjo9VjLY3sdulKIusbPf7kRCvLO/jJcy64TQ2JQT8dQAcoX XOOD4JPsCtcTLLZo2/yNjP4quB2CPSdM8RNoDweJOHCryenwQnKfE+mq/m9ZEKB1 suqIqSZcvqkAaUaQ4q51FG4ke6r/xz3+g1OcyP3y6+jHIJdAdxr2tnrwm8+QtnE4 F328OFgxb9fWfe4/MGYlSbx1c8/JnU+1uFUpfy5qYSJhRqFM1SNb4j6QS0TRnpUn oaiBDveW8vp3kUwVHc1On8alpKkoS3XlgnqlsSAcqKXi4GuHHlzMvODqRqXWhbud OJSsrZkAm8JPx+MvbZ4M58fIgTja3QGlVlPr25vlPC5odNQfMEJVskcAMtDFe4mu SNgqXk/Gpv7BO1Wzc0TqvUrGXUb3LDAhVcRGI3xqBSJEUCwrU32aXu5fVK/mGlPN wqo/FCUqK05EO0DAlDqj =cJPt -----END PGP SIGNATURE-----
