Vulnerability Development mailing list archives

Re: Hesiod security


From: Matt Power <mhpower () bos bindview com>
Date: Thu, 6 Jun 2002 22:04:33 -0400

From: KF <dotslash () snosoft com>
...
Hesiod, developed by MIT Project Athena, is an information service built
upon BIND.
...
 strcpy(bindname, name);
^----------------- here is our problem.

In the version of Hesiod used internally at MIT, this was fixed in
September 1997. See http://diswww.mit.edu/menelaus/bugs/15502

I'm aware that the latest distribution of Hesiod in the directory
ftp://athena-dist.mit.edu/pub/ATHENA/hesiod/ does not contain a fix
for this problem. There may also be other buffer overflows, or other
implementation problems, in Hesiod that were fixed at MIT or elsewhere
and are not incorporated in the athena-dist.mit.edu distribution. (And
there may be other such problems in Hesiod that no one has fixed.) The
"strcpy(bindname, name)" problem was also noted by other persons, and
some other distributions of Hesiod (for example, ones that are part of
a libc) have made different code changes in response to this problem.

                                                     ... If you could
spoof a reply for uid 0 I think you could take advantage of this.

An application (such as a login program) that trusts data from Hesiod
typically does not assign uid 0 on the basis of a Hesiod reply that
specifies uid 0. For some applications, the assigned uid must not
match the uid in the local /etc/passwd file for a different username.
For example, if the login program obtained authentication for user
johndoe, and received a Hesiod reply saying johndoe has uid 0, it
would determine via /etc/passwd that uid 0 belongs to root rather than
johndoe, and refuse to log in johndoe. In other applications, there is
a minimum uid (e.g., 100) that may be assigned on the basis of a
Hesiod reply. Still, via spoofing a Hesiod reply, an attacker can
obtain one of many possible high-numbered uids that are not his own.

Systems that use Hesiod typically have some arrangements that reduce
the risk of one user effectively attacking or impersonating a victim
user by means of obtaining the victim user's uid. As an example, the
arrangements might include no local files, no network resources that
use uid-based authentication, and the attacking user and victim user
can't have processes running simultaneously because of session
interlocking. This can make it somewhat difficult for an attacking
user (who relies on uid spoofing) to do much beyond denying service to
the victim user. In many cases, it is easier to spoof the victim
user's shell when the victim user logs in, and thereby gain control
over all aspects of the victim user's login session.

Spoofing risks may sometimes be smaller if Hesiod is used with DNSSEC.

Matt Power
BindView Corporation, RAZOR Team
mhpower () bos bindview com


Current thread: