Bug 1360743 (CVE-2016-6354) - CVE-2016-6354 flex: buffer overflow in generated code (yy_get_next_buffer)
Summary: CVE-2016-6354 flex: buffer overflow in generated code (yy_get_next_buffer)
Keywords:
Status: CLOSED WONTFIX
Alias: CVE-2016-6354
Product: Security Response
Classification: Other
Component: vulnerability
Version: unspecified
Hardware: All
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Red Hat Product Security
QA Contact:
URL:
Whiteboard:
Depends On: 1360744
Blocks: 1360746
TreeView+ depends on / blocked
 
Reported: 2016-07-27 11:46 UTC by Martin Prpič
Modified: 2019-09-29 13:54 UTC (History)
4 users (show)

Fixed In Version: flex 2.6.1
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2017-12-14 05:56:04 UTC


Attachments (Terms of Use)

Description Martin Prpič 2016-07-27 11:46:07 UTC
It was found that flex incorrectly resized the num_to_read variable in yy_get_next_buffer. 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 possible to exploit this remotely, depending on the application that is build using flex.

References:

http://seclists.org/oss-sec/2016/q3/97

Upstream patch:

https://github.com/westes/flex/commit/a5cbe929ac3255d371e698f62dc256afe7006466

Comment 1 Martin Prpič 2016-07-27 11:46:22 UTC
Created flex tracking bugs for this issue:

Affects: fedora-all [bug 1360744]

Comment 2 Fedora Update System 2016-08-08 20:28:03 UTC
flex-2.6.0-2.fc24 has been pushed to the Fedora 24 stable repository. If problems still persist, please make note of it in this bug report.

Comment 3 Doran Moppert 2016-08-23 02:16:21 UTC
This flaw was introduced in flex-2.5.36, fixed in 2.6.1.

Comment 4 Doran Moppert 2016-08-23 02:29:25 UTC
Testing with flex-2.5.37 on rhel-7 and using a simple lexer that consumes
arbitrarily long tokens, I have been unable to cause a segmentation
fault or oob read (using valgrind and clang/asan).

Instrumenting the generated lex.yy.c to track yyalloc()/yyrealloc(), the
lexer's behaviour seems to be safe.  I think the potential security impact
is mitigated by the following code immediately after the affected loop,
which constrains the max number of bytes read to 8192:

    if ( num_to_read > YY_READ_BUF_SIZE )
        num_to_read = YY_READ_BUF_SIZE;

Once num_to_read reaches 0, the buffer is reallocated correctly and filled
in 8192-byte (or smaller) chunks.

Looks like this may not be a security flaw at all, though this analysis
should be confirmed with upstream.


Note You need to log in before you can comment on or make changes to this bug.