Bug 1360743 (CVE-2016-6354)

Summary:	CVE-2016-6354 flex: buffer overflow in generated code (yy_get_next_buffer)
Product:	[Other] Security Response	Reporter:	Martin Prpič <mprpic>
Component:	vulnerability	Assignee:	Red Hat Product Security <security-response-team>
Status:	CLOSED WONTFIX	QA Contact:
Severity:	medium	Docs Contact:
Priority:	medium
Version:	unspecified	CC:	adrian, fidencio, me, pfrankli
Target Milestone:	---	Keywords:	Security
Target Release:	---
Hardware:	All
OS:	Linux
Whiteboard:
Fixed In Version:	flex 2.6.1	Doc Type:	If docs needed, set a value
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2017-12-14 05:56:04 UTC	Type:	---
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:
Bug Depends On:	1360744
Bug Blocks:	1360746

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.