Bugzilla will be upgraded to version 5.0. The upgrade date is tentatively scheduled for 2 December 2018, pending final testing and feedback.
Bug 1165192 - (CVE-2014-8121) CVE-2014-8121 glibc: Unexpected closing of nss_files databases after lookups causes denial of service
CVE-2014-8121 glibc: Unexpected closing of nss_files databases after lookups ...
Status: NEW
Product: Security Response
Classification: Other
Component: vulnerability (Show other bugs)
unspecified
All Linux
low Severity low
: ---
: ---
Assigned To: Red Hat Product Security
impact=low,public=20150223,reported=2...
: Security
Depends On: 1182272 1195201
Blocks: 1121513 1165194
  Show dependency treegraph
 
Reported: 2014-11-18 09:29 EST by Vasyl Kaigorodov
Modified: 2017-01-30 04:41 EST (History)
12 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
It was found that the files back end of Name Service Switch (NSS) did not isolate iteration over an entire database from key-based look-up API calls. An application performing look-ups on a database while iterating over it could enter an infinite loop, leading to a denial of service.
Story Points: ---
Clone Of:
Environment:
Last Closed:
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
glibc-rh1165192.patch (574 bytes, patch)
2014-11-24 11:00 EST, Florian Weimer
no flags Details | Diff
glibc-rh1165192.patch (4.28 KB, patch)
2015-01-14 16:42 EST, Florian Weimer
no flags Details | Diff
Patch to be submitted upstream (7.61 KB, patch)
2015-02-17 06:43 EST, Florian Weimer
no flags Details | Diff


External Trackers
Tracker ID Priority Status Summary Last Updated
Sourceware 18007 None None None Never
Red Hat Product Errata RHSA-2015:0327 normal SHIPPED_LIVE Moderate: glibc security and bug fix update 2015-03-05 07:10:38 EST

  None (edit)
Description Vasyl Kaigorodov 2014-11-18 09:29:26 EST
IssueDescription:

The "files" backend for the Name Service Switch (NSS) in glibc does not properly isolate iteration over the entire database from key-based lookups.  As a result, an application which performs lookups on a database while iterating over it could enter an infinite loop, leading to a denial of service.

Acknowledgements:

This issue was discovered by Robin Hack of Red Hat.
Comment 4 Florian Weimer 2014-11-19 14:40:50 EST
Analysis:

Running the test case under strace shows that /etc/passwd is continuously opened and closed:

…
open("/etc/passwd", O_RDONLY|O_CLOEXEC) = 3
lseek(3, 0, SEEK_CUR)                   = 0
read(3, "root:x:0:0:root:/root:/bin/bash\n"..., 4096) = 2717
lseek(3, 2717, SEEK_SET)                = 2717
close(3)                                = 0
open("/etc/passwd", O_RDONLY|O_CLOEXEC) = 3
lseek(3, 0, SEEK_CUR)                   = 0
lseek(3, 0, SEEK_SET)                   = 0
read(3, "root:x:0:0:root:/root:/bin/bash\n"..., 4096) = 2717
lseek(3, 2717, SEEK_SET)                = 2717
close(3)                                = 0
open("/etc/passwd", O_RDONLY|O_CLOEXEC) = 3
lseek(3, 0, SEEK_CUR)                   = 0
…

The lookup function implementation in nss/nss_files/files-XXX.c:DB_LOOKUP has code to prevent that.  It is supposed skip closing the input file if it was already open.

  /* Reset file pointer to beginning or open file.  */			      \
  status = internal_setent (keep_stream);				      \
									      \
  if (status == NSS_STATUS_SUCCESS)					      \
    {									      \
      /* Tell getent function that we have repositioned the file pointer.  */ \
      last_use = getby;							      \
									      \
      while ((status = internal_getent (result, buffer, buflen, errnop	      \
					H_ERRNO_ARG EXTRA_ARGS_VALUE))	      \
	     == NSS_STATUS_SUCCESS)					      \
	{ break_if_match }						      \
									      \
      if (! keep_stream)						      \
	internal_endent ();						      \
    }									      \

keep_stream is initialized from the stayopen flag in internal_setent.  internal_setent is called from the set*ent implementation as:

  status = internal_setent (stayopen);

However, for non-host database, this flag is always 0, per the STAYOPEN magic in nss/getXXent_r.c.

Thus, the fix is this:

-  status = internal_setent (stayopen);
+  status = internal_setent (1);

This is not a behavioral change even for the hosts database (where the application can specify the stayopen flag) because with a call to sethostent(0), the file handle is still not closed in the implementation of gethostent.
Comment 6 Florian Weimer 2014-11-24 11:00:18 EST
Created attachment 960834 [details]
glibc-rh1165192.patch

Proposed patch (without test case)
Comment 14 Florian Weimer 2015-01-14 16:42:30 EST
Created attachment 980211 [details]
glibc-rh1165192.patch

Updated patch with a test case
Comment 16 Florian Weimer 2015-02-17 06:43:17 EST
Created attachment 992644 [details]
Patch to be submitted upstream
Comment 17 Florian Weimer 2015-02-23 06:11:09 EST
Created glibc tracking bugs for this issue:

Affects: fedora-all [bug 1195201]
Comment 18 errata-xmlrpc 2015-03-05 02:18:35 EST
This issue has been addressed in the following products:

  Red Hat Enterprise Linux 7

Via RHSA-2015:0327 https://rhn.redhat.com/errata/RHSA-2015-0327.html
Comment 19 Martin Prpič 2015-03-30 03:28:17 EDT
Statement:

This issue affects the versions of glibc as shipped with Red Hat Enterprise Linux 6. Red Hat Product Security has rated this issue as having Low security impact. A future update may address this issue. For additional information, refer to the Issue Severity Classification: https://access.redhat.com/security/updates/classification/.

Red Hat Enterprise Linux 5 is now in Production 3 Phase of the support and maintenance life cycle. This issue has been rated as having Low security impact and is not currently planned to be addressed in future updates. For additional information, refer to the Red Hat Enterprise Linux Life Cycle: https://access.redhat.com/support/policy/updates/errata/.

Note You need to log in before you can comment on or make changes to this bug.