Date: Tue, 26 Jul 2016 19:52:19 -0400 (EDT) From: cve-assign@...re.org To: asulfrian@...AT.FU-Berlin.DE Cc: cve-assign@...re.org, oss-security@...ts.openwall.com Subject: Re: CVE request: flex: Buffer overflow in generated code (yy_get_next_buffer) -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 > flex upstream change some integer type in 2.5.36 to unsigned integer > types (size_t). Especially the num_to_read variable in > yy_get_next_buffer is critical, because the buffer is resized if this > value is _less_ or equal to zero. > > With special crafted input it is possible, that the buffer is not > resized if the input is larger than the default buffer size of 16k. This > allows a heap buffer overflow. > > It may be also remote usable, it depends on the software that is build > using flex. We noticed for example, that bogofilter segfaults sometimes > depending on the incoming mail. > > Upstream already noticed that this may be a problem but did not > escalate it as a security issue. Use CVE-2016-6354 for this num_to_read issue. > Upstream also changed some other type > back from size_t to int (for example in ) so maybe it is not > sufficient to only change num_to_read back to int. > > The upstream fix is contained in 2.6.1, but there are more integer type > fixes in the master branch of flex (currently not in a released > version). > > As the issue is in the generated code during compile time, it is not > sufficient to fix flex, but all binaries using flex as build-dependency > may need a rebuild after fixing flex. Additionally there may be packages, > that supply the generated source in the release-tar and do not use flex > during building. > 1: https://github.com/westes/flex/commit/9ba3187a537d6a58d345f2874d06087fd4050399 > 2: https://github.com/westes/flex/commit/a5cbe929ac3255d371e698f62dc256afe7006466 > 3: https://github.com/westes/flex/commit/7a7c3dfe1bcb8230447ba1656f926b4b4cdfc457 As far as we know, there has not been any discussion specifically showing that there is a security issue associated with any of the changes other than the num_to_read change. Accordingly, there are no other CVE IDs at this time. 7a7c3dfe1bcb8230447ba1656f926b4b4cdfc457 refers to "sf 184, 187" - in other words, https://sourceforge.net/p/flex/bugs/184/ https://sourceforge.net/p/flex/bugs/187/ Among the concerns cited is "POSIX mandates that yyleng has type int, but flex defines it as yy_size_t. This breaks programs that use the POSIX-compatible declaration." The MITRE CVE team has not been studying 7a7c3dfe1bcb8230447ba1656f926b4b4cdfc457 or the mentioned master-branch commits - the only point is that integer types sometimes need to be changed without a security-related motivation. - -- 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 iQIcBAEBCAAGBQJXl/dBAAoJEHb/MwWLVhi2lpAP/RsWLefTG5FJUYhTUPpjU8pZ lcbXV25XxNM3WMUoiVLMUnXAd+ZfVUQGWVgU4ZgXSXfuxLz5gdfoePPUJZ/d44py nWcCfrXMBN7a4I1/YYzFmH2pA1i/QGY36XqJlxFRwDneCYJ9wDRpzAjqaEJMIe21 NJjTVd//X+nmcGRRbFlvBwMGp84Ajjuxotia1Fymqcsdv5KMF2btOiw5jgWPd4mo sFj4nR594LEfJn5lCU39vNcVzWQtRzxewQwamesED6EId3VhuOCcm70JJ+lez4n4 gYdeew1MZw6P+Lc6nLqE7Fjtwl6mkKT8JrAkQCtLq2EtkmQn4MppOm2gf7XDyzOF Vkoc/r0Bw7wlL0DrRWOEV2LUlMjO2MR7WIc/PTalGje3RVZRSFVY0hEJZ9e3zWkG YoTqrLn3i48t4/1hAS5FddHlDrH95/xreubKqcolE5WNLAOdCiEWGj1pgqZGA17J PHQ2jxi34hyAK9Ob4BaB8rPrBe4iP9GytBsyrtQ2o2rRCu6g4CLzrUil7IDZOkWW LtXPDaY/+ZDgq8luebVxrkmcDnWJO7yCu2OgT0NPvoQlCnqFpUQ8jrv/T6MgBucd 7HaIydewUc96qmx1eSsnICcoXbelJt36n5ipiPLOaDikXMVKznpgeSBagHWVpVSj 5Nz46batU7sC/BdPWUos =YRxV -----END PGP SIGNATURE-----
Powered by blists - more mailing lists
Please check out the Open Source Software Security Wiki, which is counterpart to this mailing list.
Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.