CVE-2014-8121: Fix nss_files file management [BZ#18007]
Commit Message
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?
Comments
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.
@@ -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
@@ -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.
@@ -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)
{
new file mode 100644
@@ -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