Bug 1099235
| Summary: | CVE-2015-5277 glibc: nss_files doesn't detect ERANGE problems correctly [rhel-7.3] | ||||||
|---|---|---|---|---|---|---|---|
| Product: | Red Hat Enterprise Linux 7 | Reporter: | Nalin Dahyabhai <nalin> | ||||
| Component: | glibc | Assignee: | Marek Polacek <mpolacek> | ||||
| Status: | CLOSED ERRATA | QA Contact: | Arjun Shankar <ashankar> | ||||
| Severity: | high | Docs Contact: | |||||
| Priority: | medium | ||||||
| Version: | 7.3 | CC: | ashankar, ekeck, fweimer, mnewsome, mpolacek, pfrankli, pkis, rhbugs, t.h.amundsen, tjuberg | ||||
| Target Milestone: | rc | Keywords: | Patch, Security, SecurityTracking, ZStream | ||||
| Target Release: | --- | ||||||
| Hardware: | Unspecified | ||||||
| OS: | Unspecified | ||||||
| Whiteboard: | |||||||
| Fixed In Version: | glibc-2.17-106.el7 | Doc Type: | Bug Fix | ||||
| Doc Text: |
It was discovered that the nss_files backend for the Name Service Switch in glibc would return incorrect data to applications or corrupt the heap (depending on adjacent heap contents). A local attacker could potentially use this flaw to execute arbitrary code on the system.
|
Story Points: | --- | ||||
| Clone Of: | Environment: | ||||||
| Last Closed: | 2016-11-03 08:21:31 UTC | Type: | Bug | ||||
| 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: | |||||||
| Bug Blocks: | 1098616, 1110700, 1191021, 1262914 | ||||||
| Attachments: |
|
||||||
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>
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> 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 |
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