Re: Hesiod security

From: Matt Power (mhpowerat_private)
Date: Thu Jun 06 2002 - 19:04:33 PDT

  • Next message: Kayne Ian (Softlab): "RE: Phone Switches + telephone banking etc"

    >From: KF <dotslashat_private>
    ...
    >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
    mhpowerat_private
    



    This archive was generated by hypermail 2b30 : Thu Jun 06 2002 - 20:28:51 PDT