russell@ccu1.aukuni.ac.nz (Russell J Fulton;ccc032u) (03/19/91)
We are running a SGI 4D system with Irix 3.3.2. We have noticed that cuserid sometimes (about 5% of the time) will return the wrong information i.e. the login name of some other user. Silicon Graphics said that this is a known problem in Unix (presumably SYS V) and therefore the could not do anything about it. The problem, I gather, is that the information in the /etc/utmp file sometimes gets out of sync or something. Or more likely, that there is a delay in updating the information so that there exist a time window during which the the information is incorrect. I would like to hear from anybody who can comment on the following: 1/ is this in fact a general problem? 2/ if it is then who should we hit to get it fixed? It is a nasty security loop hole for the unwary. We had a setuid program which used cuserid to check identity of the person running the program and allowed them to do different things depending on who they are. One of our users rang up to say that they had the manager's menus coming up! We now use getuid to check identity. Thanks, Russell. -- Russell Fulton, Computer Center, University of Auckland, New Zealand. <rj_fulton@aukuni.ac.nz>
xtdn@levels.sait.edu.au (03/23/91)
russell@ccu1.aukuni.ac.nz (Russell J Fulton;ccc032u) writes: > It is a nasty security loop hole for the unwary. We had a setuid program > which used cuserid to check identity of the person running the program cuserid does not return the calling user's identity; rather it returns the login name, as recorded in utmp, of the user logged in to the terminal that is the caller's stdin, stdout and/or stderr. Or to put this more clearly: return-cuserid < /dev/console >/dev/console 2>/dev/console will return the login id of whoever is logged in on /dev/console. Using cuserid to verify the identity of the caller is a security hole that just begs to be exploited. Used in conjunction with getuid, it can be useful. David Newall, who no longer works Phone: +61 8 344 2008 for SA Institute of Technology E-mail: xtdn@lux.sait.edu.au "Life is uncertain: Eat dessert first"
jfh@rpp386.cactus.org (John F Haugh II) (03/26/91)
In article <16040.27eab416@levels.sait.edu.au> xtdn@levels.sait.edu.au writes: >russell@ccu1.aukuni.ac.nz (Russell J Fulton;ccc032u) writes: >> It is a nasty security loop hole for the unwary. We had a setuid program >> which used cuserid to check identity of the person running the program > >Using cuserid to verify the identity of the caller is a security hole >that just begs to be exploited. Used in conjunction with getuid, it >can be useful. The best way to determine user ID is to get the login name from the utmp file and look it up in the password file. If the uid from the password file matches the current user ID, assume you got the right name. Otherwise, take the current user ID and look it up in the password file. Use the name that you get back. This can fail in different ways, such as if there are non-unique user ID's. This is far from perfect and points to the usefulness of the "login id" or "privileged environment". Both of these concepts can be found in various systems, such as those provided by SecureWare and Locus Computing. -- John F. Haugh II | Distribution to | UUCP: ...!cs.utexas.edu!rpp386!jfh Ma Bell: (512) 832-8832 | GEnie PROHIBITED :-) | Domain: jfh@rpp386.cactus.org "I want to be Robin to Bush's Batman." -- Vice President Dan Quayle