Message ID | 54EB120A.1010202@redhat.com |
---|---|
State | New |
Headers | show |
Florian Weimer <fweimer@redhat.com> writes: > Robin Hack discovered that Samba would enter an infinite loop when > processing quota-related requests. It turns out this is a bug in the > nss_files database. Performing a lookup in the middle of an iteration > (say, getwuid between getpwent) effectively resets the file pointer, so > that the iteration starts again from the beginning. > > Tested on x86_64-redhat-linux-gnu. Okay to commit? That doesn't fix the bug. It still fails with a nis config. Andreas.
On 02/23/2015 01:00 PM, Andreas Schwab wrote: > Florian Weimer <fweimer@redhat.com> writes: > >> Robin Hack discovered that Samba would enter an infinite loop when >> processing quota-related requests. It turns out this is a bug in the >> nss_files database. Performing a lookup in the middle of an iteration >> (say, getwuid between getpwent) effectively resets the file pointer, so >> that the iteration starts again from the beginning. >> >> Tested on x86_64-redhat-linux-gnu. Okay to commit? > > That doesn't fix the bug. It still fails with a nis config. Ugh, could you please elaborate?
Florian Weimer <fweimer@redhat.com> writes: > On 02/23/2015 01:00 PM, Andreas Schwab wrote: >> Florian Weimer <fweimer@redhat.com> writes: >> >>> Robin Hack discovered that Samba would enter an infinite loop when >>> processing quota-related requests. It turns out this is a bug in the >>> nss_files database. Performing a lookup in the middle of an iteration >>> (say, getwuid between getpwent) effectively resets the file pointer, so >>> that the iteration starts again from the beginning. >>> >>> Tested on x86_64-redhat-linux-gnu. Okay to commit? >> >> That doesn't fix the bug. It still fails with a nis config. > > Ugh, could you please elaborate? $ grep ^passwd /etc/nsswitch.conf passwd: compat Andreas.
On 02/23/2015 01:56 PM, Andreas Schwab wrote: > Florian Weimer <fweimer@redhat.com> writes: > >> On 02/23/2015 01:00 PM, Andreas Schwab wrote: >>> Florian Weimer <fweimer@redhat.com> writes: >>> >>>> Robin Hack discovered that Samba would enter an infinite loop when >>>> processing quota-related requests. It turns out this is a bug in the >>>> nss_files database. Performing a lookup in the middle of an iteration >>>> (say, getwuid between getpwent) effectively resets the file pointer, so >>>> that the iteration starts again from the beginning. >>>> >>>> Tested on x86_64-redhat-linux-gnu. Okay to commit? >>> >>> That doesn't fix the bug. It still fails with a nis config. >> >> Ugh, could you please elaborate? > > $ grep ^passwd /etc/nsswitch.conf > passwd: compat Are you trying to say that the code in nis/nss_compat/*.c has similar bugs?
Florian Weimer <fweimer@redhat.com> writes: > On 02/23/2015 01:56 PM, Andreas Schwab wrote: >> Florian Weimer <fweimer@redhat.com> writes: >> >>> On 02/23/2015 01:00 PM, Andreas Schwab wrote: >>>> Florian Weimer <fweimer@redhat.com> writes: >>>> >>>>> Robin Hack discovered that Samba would enter an infinite loop when >>>>> processing quota-related requests. It turns out this is a bug in the >>>>> nss_files database. Performing a lookup in the middle of an iteration >>>>> (say, getwuid between getpwent) effectively resets the file pointer, so >>>>> that the iteration starts again from the beginning. >>>>> >>>>> Tested on x86_64-redhat-linux-gnu. Okay to commit? >>>> >>>> That doesn't fix the bug. It still fails with a nis config. >>> >>> Ugh, could you please elaborate? >> >> $ grep ^passwd /etc/nsswitch.conf >> passwd: compat > > Are you trying to say that the code in nis/nss_compat/*.c has similar bugs? I don't know, I haven't been able to analyze it yet. Andreas.
On 02/23/2015 12:42 PM, Florian Weimer wrote: > Robin Hack discovered that Samba would enter an infinite loop when > processing quota-related requests. It turns out this is a bug in the > nss_files database. Performing a lookup in the middle of an iteration > (say, getwuid between getpwent) effectively resets the file pointer, so > that the iteration starts again from the beginning. > > Tested on x86_64-redhat-linux-gnu. Okay to commit? Ping? Can we at least fix the most common instance of this bug?
On Mon, Mar 16, 2015 at 04:00:32PM +0100, Florian Weimer wrote: > On 02/23/2015 12:42 PM, Florian Weimer wrote: > > Robin Hack discovered that Samba would enter an infinite loop when > > processing quota-related requests. It turns out this is a bug in the > > nss_files database. Performing a lookup in the middle of an iteration > > (say, getwuid between getpwent) effectively resets the file pointer, so > > that the iteration starts again from the beginning. > > > > Tested on x86_64-redhat-linux-gnu. Okay to commit? > > Ping? > > Can we at least fix the most common instance of this bug? I agree. Patch looks good to me. Siddhesh
Florian Weimer <fweimer@redhat.com> writes: > On 02/23/2015 12:42 PM, Florian Weimer wrote: >> Robin Hack discovered that Samba would enter an infinite loop when >> processing quota-related requests. It turns out this is a bug in the >> nss_files database. Performing a lookup in the middle of an iteration >> (say, getwuid between getpwent) effectively resets the file pointer, so >> that the iteration starts again from the beginning. >> >> Tested on x86_64-redhat-linux-gnu. Okay to commit? > > Ping? > > Can we at least fix the most common instance of this bug? It's the wrong way to fix the bug. The getpwuid function should use a separate state local to this function, with _all_ backends. Andreas.
* Andreas Schwab: > Florian Weimer <fweimer@redhat.com> writes: > >> On 02/23/2015 12:42 PM, Florian Weimer wrote: >>> Robin Hack discovered that Samba would enter an infinite loop when >>> processing quota-related requests. It turns out this is a bug in the >>> nss_files database. Performing a lookup in the middle of an iteration >>> (say, getwuid between getpwent) effectively resets the file pointer, so >>> that the iteration starts again from the beginning. >>> >>> Tested on x86_64-redhat-linux-gnu. Okay to commit? >> >> Ping? >> >> Can we at least fix the most common instance of this bug? > > It's the wrong way to fix the bug. The getpwuid function should use a > separate state local to this function, with _all_ backends. Sorry, I don't see how this can be retrofitted on top of the existing NSS API. It assumes that the NSS module keeps the iteration state in a per-module global variable. The fix I proposed builds on Ulrich's original patch which attempted to separate the state for lookup and iteration, but failed to do so because of that incorrectly initialized variable. We didn't notice this because there was no test. I can fix the other modules as well if someone can provide instructions how to set up test environments.
Florian Weimer <fw@deneb.enyo.de> writes: > Sorry, I don't see how this can be retrofitted on top of the existing > NSS API. It assumes that the NSS module keeps the iteration state in > a per-module global variable. That's the bug. > The fix I proposed builds on Ulrich's original patch which attempted > to separate the state for lookup and iteration, but failed to do so > because of that incorrectly initialized variable. There is no "incorrectly initialized variable". Andreas.
* Andreas Schwab: > Florian Weimer <fw@deneb.enyo.de> writes: > >> Sorry, I don't see how this can be retrofitted on top of the existing >> NSS API. It assumes that the NSS module keeps the iteration state in >> a per-module global variable. > > That's the bug. Maybe. But we cannot remove the old API (there are external NSS modules, after all). Therefore, such a change would only increase complexity. If we had tests, I think a better first step would be to reduce code duplication between the NSS modules glibc ships, and clean up the #include file mess. But without tests, such changes offer a poor risk/benefit trade-off. >> The fix I proposed builds on Ulrich's original patch which attempted >> to separate the state for lookup and iteration, but failed to do so >> because of that incorrectly initialized variable. > > There is no "incorrectly initialized variable". Ahem, I think the commit message of my patch explains this quite clearly. The code Ulrich added to deal with this corner case didn't work as intended because a flag was not set correctly.
Florian Weimer <fw@deneb.enyo.de> writes: > Maybe. But we cannot remove the old API (there are external NSS > modules, after all). Therefore, such a change would only increase > complexity. There is no way around. > Ahem, I think the commit message of my patch explains this quite > clearly. The code Ulrich added to deal with this corner case didn't > work as intended because a flag was not set correctly. Since it doesn't fix the bug, it doesn't make sense. Andreas.
* Andreas Schwab: > Florian Weimer <fw@deneb.enyo.de> writes: > >> Maybe. But we cannot remove the old API (there are external NSS >> modules, after all). Therefore, such a change would only increase >> complexity. > > There is no way around. Andreas, your discussion style is really unhelpful. You only post one-line oblique assertions. I have to guess what you actually mean. I certainly value your expertise and input, but this is now too frustrating to keep going. >> Ahem, I think the commit message of my patch explains this quite >> clearly. The code Ulrich added to deal with this corner case didn't >> work as intended because a flag was not set correctly. > > Since it doesn't fix the bug, it doesn't make sense. It fixes the bug for all the nss_files back end, and this has been verified by multiple people. The fix also matches my root cause analysis (included in the commit message). If you think this analysis is wrong and fails to explain why Ulrich's original attempt to fix this bug didn't work, please point out precisely where my reasoning goes off thhe tracks.
On 03/25/2015 06:47 AM, Siddhesh Poyarekar wrote: > On Mon, Mar 16, 2015 at 04:00:32PM +0100, Florian Weimer wrote: >> On 02/23/2015 12:42 PM, Florian Weimer wrote: >>> Robin Hack discovered that Samba would enter an infinite loop >>> when processing quota-related requests. It turns out this is a >>> bug in the nss_files database. Performing a lookup in the >>> middle of an iteration (say, getwuid between getpwent) >>> effectively resets the file pointer, so that the iteration >>> starts again from the beginning. >>> >>> Tested on x86_64-redhat-linux-gnu. Okay to commit? >> >> Ping? >> >> Can we at least fix the most common instance of this bug? > > I agree. Patch looks good to me. Should I commit this in the interim, until we can get Andreas' more comprehensive patch reviewed?
On 04/01/2015 07:54 PM, Florian Weimer wrote: > On 03/25/2015 06:47 AM, Siddhesh Poyarekar wrote: >> On Mon, Mar 16, 2015 at 04:00:32PM +0100, Florian Weimer wrote: >>> On 02/23/2015 12:42 PM, Florian Weimer wrote: >>>> Robin Hack discovered that Samba would enter an infinite loop >>>> when processing quota-related requests. It turns out this is a >>>> bug in the nss_files database. Performing a lookup in the >>>> middle of an iteration (say, getwuid between getpwent) >>>> effectively resets the file pointer, so that the iteration >>>> starts again from the beginning. >>>> >>>> Tested on x86_64-redhat-linux-gnu. Okay to commit? >>> >>> Ping? >>> >>> Can we at least fix the most common instance of this bug? >> >> I agree. Patch looks good to me. > > Should I commit this in the interim, until we can get Andreas' more > comprehensive patch reviewed? I have committed this now. After all, even with Andreas' patch, the test case is still relevant.
From a2f8ecd45e140df1b1d2b09c58817fb3b8470587 Mon Sep 17 00:00:00 2001 From: Florian Weimer <fweimer@redhat.com> Date: Mon, 23 Feb 2015 12:33:16 +0100 Subject: [PATCH] CVE-2014-8121: Do not close NSS files database during iteration [BZ #18007] MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Robin Hack discovered Samba would enter an infinite loop processing certain quota-related requests. We eventually tracked this down to a glibc issue. Running a (simplified) 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. 2015-02-23 Florian Weimer <fweimer@redhat.com> [BZ #18007] * nss/nss_files/files-XXX.c (CONCAT): Always enable stayopen. (CVE-2014-8121) * nss/tst-nss-getpwent.c: New file. * nss/Makefile (tests): Add new test. diff --git a/NEWS b/NEWS index 28ef45d..109c5c3 100644 --- a/NEWS +++ b/NEWS @@ -11,13 +11,17 @@ Version 2.22 4719, 13064, 14094, 15319, 15467, 15790, 16560, 17269, 17569, 17588, 17792, 17912, 17932, 17944, 17949, 17964, 17965, 17967, 17969, 17978, - 17987, 17991, 17996, 17998, 17999. + 17987, 17991, 17996, 17998, 17999, 18007. * Character encoding and ctype tables were updated to Unicode 7.0.0, using new generator scripts contributed by Pravin Satpute and Mike FABIAN (Red Hat). These updates cause user visible changes, such as the fix for bug 17998. +* CVE-2014-8121 The NSS files backend would reset the file pointer used by + the get*ent functions if any of the query functions for the same database + are used during the iteration, causing a denial-of-service condition in + some applications. Version 2.21 diff --git a/nss/Makefile b/nss/Makefile index d75dad2..65ab7b5 100644 --- a/nss/Makefile +++ b/nss/Makefile @@ -47,7 +47,7 @@ install-bin := getent makedb makedb-modules = xmalloc hash-string extra-objs += $(makedb-modules:=.o) -tests = test-netdb tst-nss-test1 test-digits-dots +tests = test-netdb tst-nss-test1 test-digits-dots tst-nss-getpwent xtests = bug-erange # Specify rules for the nss_* modules. We have some services. diff --git a/nss/nss_files/files-XXX.c b/nss/nss_files/files-XXX.c index a7a45e5..a7ce5ea 100644 --- a/nss/nss_files/files-XXX.c +++ b/nss/nss_files/files-XXX.c @@ -134,7 +134,7 @@ CONCAT(_nss_files_set,ENTNAME) (int stayopen) __libc_lock_lock (lock); - status = internal_setent (stayopen); + status = internal_setent (1); if (status == NSS_STATUS_SUCCESS && fgetpos (stream, &position) < 0) { diff --git a/nss/tst-nss-getpwent.c b/nss/tst-nss-getpwent.c new file mode 100644 index 0000000..f2e8abc --- /dev/null +++ b/nss/tst-nss-getpwent.c @@ -0,0 +1,118 @@ +/* Copyright (C) 2015 Free Software Foundation, Inc. + This file is part of the GNU C Library. + + The GNU C Library is free software; you can redistribute it and/or + modify it under the terms of the GNU Lesser General Public + License as published by the Free Software Foundation; either + version 2.1 of the License, or (at your option) any later version. + + The GNU C Library is distributed in the hope that it will be useful, + but WITHOUT ANY WARRANTY; without even the implied warranty of + MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU + Lesser General Public License for more details. + + You should have received a copy of the GNU Lesser General Public + License along with the GNU C Library; if not, see + <http://www.gnu.org/licenses/>. */ + +#include <pwd.h> +#include <stdbool.h> +#include <stdio.h> +#include <stdlib.h> +#include <string.h> + +int +do_test (void) +{ + /* Count the number of entries in the password database, and fetch + data from the first and last entries. */ + size_t count = 0; + struct passwd * pw; + char *first_name = NULL; + uid_t first_uid = 0; + char *last_name = NULL; + uid_t last_uid = 0; + setpwent (); + while ((pw = getpwent ()) != NULL) + { + if (first_name == NULL) + { + first_name = strdup (pw->pw_name); + if (first_name == NULL) + { + printf ("strdup: %m\n"); + return 1; + } + first_uid = pw->pw_uid; + } + + free (last_name); + last_name = strdup (pw->pw_name); + if (last_name == NULL) + { + printf ("strdup: %m\n"); + return 1; + } + last_uid = pw->pw_uid; + ++count; + } + endpwent (); + + if (count == 0) + { + printf ("No entries in the password database.\n"); + return 0; + } + + /* Try again, this time interleaving with name-based and UID-based + lookup operations. The counts do not match if the interleaved + lookups affected the enumeration. */ + size_t new_count = 0; + setpwent (); + while ((pw = getpwent ()) != NULL) + { + if (new_count == count) + { + printf ("Additional entry in the password database.\n"); + return 1; + } + ++new_count; + struct passwd *pw2 = getpwnam (first_name); + if (pw2 == NULL) + { + printf ("getpwnam (%s) failed: %m\n", first_name); + return 1; + } + pw2 = getpwnam (last_name); + if (pw2 == NULL) + { + printf ("getpwnam (%s) failed: %m\n", last_name); + return 1; + } + pw2 = getpwuid (first_uid); + if (pw2 == NULL) + { + printf ("getpwuid (%llu) failed: %m\n", + (unsigned long long) first_uid); + return 1; + } + pw2 = getpwuid (last_uid); + if (pw2 == NULL) + { + printf ("getpwuid (%llu) failed: %m\n", + (unsigned long long) last_uid); + return 1; + } + } + endpwent (); + if (new_count < count) + { + printf ("Missing entry in the password database.\n"); + return 1; + } + + return 0; +} + +#define TEST_FUNCTION do_test () +#include "../test-skeleton.c" -- 2.1.0