CVE-2014-8121: Fix nss_files file management [BZ#18007]
diff mbox

Message ID 54EB120A.1010202@redhat.com
State New
Headers show

Commit Message

Florian Weimer Feb. 23, 2015, 11:42 a.m. UTC
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

Andreas Schwab Feb. 23, 2015, noon UTC | #1
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.
Florian Weimer Feb. 23, 2015, 12:02 p.m. UTC | #2
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?
Andreas Schwab Feb. 23, 2015, 12:56 p.m. UTC | #3
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.
Florian Weimer Feb. 23, 2015, 1 p.m. UTC | #4
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?
Andreas Schwab Feb. 23, 2015, 1:04 p.m. UTC | #5
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.
Florian Weimer March 16, 2015, 3 p.m. UTC | #6
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?
Siddhesh Poyarekar March 25, 2015, 5:47 a.m. UTC | #7
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
Andreas Schwab March 25, 2015, 8:44 a.m. UTC | #8
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.
Florian Weimer March 25, 2015, 12:27 p.m. UTC | #9
* 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.
Andreas Schwab March 25, 2015, 12:43 p.m. UTC | #10
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.
Florian Weimer March 25, 2015, 12:54 p.m. UTC | #11
* 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.
Andreas Schwab March 25, 2015, 1:05 p.m. UTC | #12
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.
Florian Weimer March 25, 2015, 1:10 p.m. UTC | #13
* 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.
Florian Weimer April 1, 2015, 5:54 p.m. UTC | #14
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?
Florian Weimer April 29, 2015, 1:18 p.m. UTC | #15
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.

Patch
diff mbox

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