oss-security - A few Hesiod issues

Follow @Openwall on Twitter for new release announcements and other news

[<prev] [next>] [day] [month] [year] [list]

Message-ID: <5729CA23.7050707@redhat.com>
Date: Wed, 4 May 2016 12:08:35 +0200
From: Florian Weimer <fweimer@...hat.com>
To: oss-security@...ts.openwall.com
Subject: A few Hesiod issues

We rediscovered a few Hesiod client issues, some of which have been 
fixed for a long time in various forks of the Hesiod client.  We did not 
assign CVE IDs because they are mostly ordinary bugs (no trust boundary 
is crossed etc.).

(a) Hard-coded default athena.mit.edu

   <https://bugzilla.redhat.com/show_bug.cgi?id=1332493>
   <https://github.com/achernya/hesiod/pull/10>

If the configuration file cannot be opened, the hesiod library will 
default to use athena.mit.edu:

#define DEF_RHS ".athena.mit.edu"
…
   /* Try to open the configuration file. */
   fp = fopen(filename, "r");
   if (!fp)
     {
       /* Use compiled in default domain names. */
       ctx->lhs = malloc(strlen(DEF_LHS) + 1);
       ctx->rhs = malloc(strlen(DEF_RHS) + 1);

This means that an attacker who can control the athena.mit.edu zone or 
one of its parent zones can supply fake Hesiod data in certain cases. 
(This would allow injection of fake root accounts, for example.)

If a Hesiod deployment uses DNSSEC with a trusted, validating recursive 
resolver to secure Hesiod data, this issue could result in retrieval of 
non-DNSSEC-signed Hesiod data (athena.mit.edu is currently unsigned).

glibc did not use a default for RHS since 2000, presumably as part of an 
update to BIND 8.2.3-T5B.  Current NetBSD sources lack a default as well.

(b) Weak AT_SECURE check

   <https://bugzilla.redhat.com/show_bug.cgi?id=1332508>
   <https://github.com/achernya/hesiod/pull/9>

hesiod checks the current EUID against the UID (and EGID against GID) in 
a few places to protect overriding certain configuration values with 
environment variables:

       configname = ((getuid() == geteuid()) && (getgid() == getegid())) 
? getenv("HESIOD_CONFIG") : NULL;

This is problematic if the process has elected to become full root, or 
otherwise made UID == EUID without dropping all privileges.  It does not 
catch SELinux transitions, either.  In such cases, local attackers who 
can set the HESIOD_CONFIG or HES_DOMAIN environment variables and run an 
affected binary with an AT_SECURE transition might be able to elevate 
their privileges.

glibc has always used secure_getenv for a long time (except for a brief 
period in 1997).  Current NetBSD source use an equivalent.

(c) A heap-based buffer overflow in TXT record parsing

  <https://sourceware.org/bugzilla/show_bug.cgi?id=20031>
  <https://github.com/achernya/hesiod/issues/11>

Hesiod treats DNS as trusted, so this is not a vulnerability.

Florian

Please check out the Open Source Software Security Wiki, which is counterpart to this mailing list.

Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.