>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