Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date: Tue, 26 Jul 2016 19:52:19 -0400 (EDT)
To: asulfrian@...AT.FU-Berlin.DE
Subject: Re: CVE request: flex: Buffer overflow in generated code (yy_get_next_buffer)

Hash: SHA256

> flex upstream change some integer type in 2.5.36[1] 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[2] 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 [3]) 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:
> 2:
> 3:

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,

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 ]
Version: GnuPG v1


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.