A bug reporter [1] that claims he has, or can produce, a code execution
exploit against grep < 2.11. I've verified that our grep 2.10 package
segfaults on the amd64 platform with the simple reproducer:
$ perl -e 'print "x"x(2**31)' | grep x > /dev/null
Segmentation fault (core dumped)
This specific problem was patched [2] with the following checkin:
http://git.savannah.gnu.org/cgit/grep.git/commit/?id=cbbc1a45b9f843c811905c97c90a5d31f8e6c189
This checkin adds this text to the NEWS file:
+ 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"]
Please assign a CVE number for this problem.
Several other checkins around the 2.11 timeframe also look like they
may be security-relevant:
PCRE over-long line fix:
http://git.savannah.gnu.org/cgit/grep.git/commit/?id=4572ea4649d025e51463d48c2d06a1c66134cdb8
Integer overflow issues:
http://git.savannah.gnu.org/cgit/grep.git/commit/?id=8fcf61523644df42e1905c81bed26838e0b04f91
Paul, are any security issues fixed with those patches? Did I overlook
any other patches that need CVE numbers?
Thanks
1: https://bugs.launchpad.net/ubuntu/+source/grep/+bug/1091473
2: http://lists.gnu.org/archive/html/bug-grep/2012-12/msg00004.html