Re: Bug#120059: nscd: nscd will use cached reverse lookups and ignore nsswitch.conf

[Arne Georg Gleditsch]

* Ben Collins
> Isn't caching the whole point of nscd? Just because you have an odd
> /etc/hosts, doesn't mean it's broken.

* Adam Hupp
> The problem is that it uses the cached reverse lookup for later forward
> lookups.  My /etc/hosts is perfectly normal, the 128.105.45.1 -> localhost
> result came from an external nameserver.  I have not tried this, but I
> think it would be easy to exploit anything that does authentication based
> on hostname.
>
> If I have foo.org in my .rhosts on machine A running nscd, an attacker
> could setup a nameserver to return foo.org for reverse lookups of their
> own ip.  Then they could rsh to A, which would do a reverse lookup of the
> incoming ip, get foo.org, and then check whether foo.org resolves back to
> the incoming ip.  Since nscd has cached the result from the origional
> reverse lookup they would match and the attacker is in.  I may be
> misunderstanding part of this, but it seems like that would work.

* Ben Collins
> No, they can't. Because the then forward look is checked before it is
> cached. It actually does resolve correctly, just not the way you want it
> to.

The fact that the problem is hidden if you are lucky enough to do the
forward lookup first doesn't make the problem disappear.  nscd is
caching false information based on conjecture, and this is a serious
bug.  Tha fact that a.b.c.d points to dom.ain does not at all imply
that dom.ain resolves to a.b.c.d.  Assuming so is a grave error and a
very real security risk.  I had this bug bite me today, when all of a
sudden my applications connecting to a database on "localhost" started
to fail just because my nscd had looked up an ip pointing to
"localhost" and cached the (completely bogus) forward entry as well as
the reverse entry.  This is not acceptable.  Tricking the database
passwords out of my application would have been piece of cake if the
person owning the culprit ip had wanted to do so, and if my database
had been accessible from the outside I could have been in for all
kinds of unpleaseant surprises.  This is a very real bug.

(For additional threat scenarios, consider domain based access control
(*.dom.ain), where the forward lookup cannot be done in advance.
You're at the mercy of whoever connects' reverse lookup, even if your
application tries to be paranoid and attempts to forward resolve the
result of all reverse lookups to check consistency.  This is not at
all good!)

As an example, try this with cold nscd caches:

  #include <netdb.h>
  #include <sys/socket.h>
  #include <netinet/in.h>
  
  int main() {
      struct hostent *a;
      struct in_addr ip;
  
      inet_aton("213.203.57.125", &ip);
  
      a = gethostbyaddr(&ip, sizeof(ip), AF_INET);
      printf("%s\n", a->h_name);
  
      a = gethostbyname(a->h_name);
      if (a)
          printf("%u.%u.%u.%u\n", 
                 (unsigned char)a->h_addr[0],
                 (unsigned char)a->h_addr[1],
                 (unsigned char)a->h_addr[2],
                 (unsigned char)a->h_addr[3]);
      else
          printf("Forward lookup failed\n");            
  }

On Debian/unstable (glibc 2.2.5) this prints

  this-does-not-resolve.linpro.no
  213.203.57.125

By just manipulating the reverse lookup, I've made it look like my
address is actually resolved from the linpro.no domain, which is
patently false.  This could potentially give me access restricted to
hosts in the linpro.no domain.

Under Debian/stable, gethostbyname seems to be more paranoid, and
performs additional lookups on its own:

  this-does-not-resolve.linpro.no
  Forward lookup failed

"strace" reveals the information handed out by nscd (glibc 2.1.3) to be
just as bogus as under unstable, though.

Please reopen this bug.


                                                        Arne.