Re: RFC: maint: prepare NEWS

[Akim Demaille]

Hi all,

> Le 30 août 2020 à 16:57, Akim Demaille <akim@lrde.epita.fr> 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 <akim.demaille@gmail.com>
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: cve-request@mitre.org
Objet: Rép : [scr951593] Bison and CVE
Date: 31 août 2020 à 04:20:53 UTC+2
À: akim.demaille@gmail.com
Cc: cve-request@mitre.org

-----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-----