Red Hat Bugzilla – Bug 1099235
CVE-2015-5277 glibc: nss_files doesn't detect ERANGE problems correctly [rhel-7.3]
Last modified: 2016-11-03 04:21:31 EDT
Created attachment 897322 [details] Test program, takes optional user name ("root") and initial buffer size (4) as arguments Description of problem: In glibc-2.17-c758a686/nss/nss_files/files-XXX.c, in get_contents(), the loop appears to be checking for a too-small passed-in buffer incorrectly, in that it assigns 0xff to the final byte in the buffer after passing the buffer to fgets_unlocked instead of before. Version-Release number of selected component (if applicable): glibc-2.17-55.el7.x86_64 How reproducible: Always Steps to Reproduce: 1. Call getpwnam_r() with bufsize set to a small number (4 in my test). Actual results: getpwnam_r() returns 0 Expected results: getpwnam_r() returns ERANGE
This is not reproducible on F21, so we probably have a patch for this already; it's just a matter of bisecting it. From a quick look, the following commit may have fixed this as a side-effect. commit 977f4b31b7ca4a4e498c397f3fd70510694bbd86 Author: Siddhesh Poyarekar <siddhesh@redhat.com> Date: Wed Oct 30 16:13:37 2013 +0530 Fix reads for sizes larger than INT_MAX in AF_INET lookup Currently for AF_INET lookups from the hosts file, buffer sizes larger than INT_MAX silently overflow and may result in access beyond bounds of a buffer. This happens when the number of results in an AF_INET lookup in /etc/hosts are very large. There are two aspects to the problem. One problem is that the size computed from the buffer size is stored into an int, which results in overflow for large sizes. Additionally, even if this size was expanded, the function used to read content into the buffer (fgets) accepts only int sizes. As a result, the fix is to have a function wrap around fgets that calls it multiple times with int sizes if necessary.
(In reply to Siddhesh Poyarekar from comment #3) > This is not reproducible on F21, so we probably have a patch for this > already; it's just a matter of bisecting it. From a quick look, the > following commit may have fixed this as a side-effect. It's not that simple. I spent some time last week trying to bisect the issue from upstream code and I couldn't. Everything right down to 2.17 seems to work correctly when in F21 and that sounds wrong. I'm going to try this again, this time on a rhel-7 box.
... and we have a winner, it is: https://sourceware.org/bugzilla/show_bug.cgi?id=17079 which was fixed by: commit ac60763eac3d43b7234dd21286ad3ec3f17957fc Author: Andreas Schwab <schwab@suse.de> Date: Mon Jun 23 10:24:45 2014 +0200 Don't ignore too long lines in nss_files (BZ #17079) I broke it in rhel-7.0 when I backported the buggy patch.
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://rhn.redhat.com/errata/RHSA-2016-2573.html