oss-sec mailing list archives

A few Hesiod issues


From: Florian Weimer <fweimer () redhat com>
Date: Wed, 4 May 2016 12:08:35 +0200

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


Current thread: