Re: Exploit in grep..

[Jim Meyering]

Jim Meyering wrote:

> Jim Meyering wrote:
>> Joshua Rogers wrote:
>>> Is this the right place to report a memory corruption vulnerability in grep?
>>
>> Thanks for asking.
>> Please be sure you're using the latest from git:
>>
>>     http://git.sv.gnu.org/cgit/grep.git
>>
>> If you think it may really be exploitable (as in arbitrary code execution),
>> it's best not to publicize it right away.  Instead, report it privately to
>> a few of the recent committers -- you can use the addresses from the git log.
>>
>> Otherwise, this list is fine.
>
> For the record, the problem Joshua noticed is that
> any input with a matching line longer than ~2GiB
> would provoke a segfault in grep prior to version 2.11, e.g.,
>
>     perl -e 'print "a"x(2**31)' | grep x > /dev/null

That didn't trigger the problem, due to a typo (no match).
This does:

      perl -e 'print "A"x(2**31)' | grep A > /dev/null

> Here's the NEWS file entry for that fix:
>
>   * Noteworthy changes in release 2.11 (2012-03-02) [stable]
>
>   ** Bug fixes
>
>     grep no longer dumps core on lines whose lengths do not fit in 'int'.
>     (e.g., lines longer than 2 GiB on a typical 64-bit host).
>     Instead, grep either works as expected, or reports an error.
>     An error can occur if not enough main memory is available, or if the
>     GNU C library's regular expression functions cannot handle such long 
> lines.
>     [bug present since "the beginning"]