Bugtraq mailing list archives

Re: Fix for ssh-1.2.27 symlink/bind problem


From: casper () HOLLAND SUN COM (Casper Dik)
Date: Fri, 29 Oct 1999 11:34:30 +0200


Markus Friedl:
Since Solaris 2.3 allowed you to attach (e.g. with gdb) to a
programm running with euid==youruid, Tatu dropped the uid-swapping
code and made ssh fork into two processes.
...
void temporarily_use_uid(uid_t uid)
{
#ifdef SAVED_IDS_WORK_WITH_SETEUID
  saved_euid = geteuid();
  if (seteuid(uid) == -1)
    debug("seteuid %d: %.100s", (int)uid, strerror(errno));
#else

ssh starts up with the unprivileged real UID of the user; therefore
setting the effective UID also to that of the user makes the process
memory accessible for unprivileged access. This is how any reasonable
UNIX system works, not just Solaris.

If a system uses saved uids, the saved uid will remain 0; in that
case you can still gain back the root uid; systems with saved uids
do (at least, should not) allow any memory access in that case.

In Solaris, we've changed the code around a few times, and these
days you cannot gain back control over the process even if your
credentials are a superset of the process' credentials.  Once a process
has been set-uid it has been marked "tainted" and it cannot be
examined/attached to with a debugger nor will it core dump.

The latest Solaris 7 patches add a "coreadm" command which allow the
system administrator to obtain cores of such processes anyway.

However, no reasonable UNIX system should allow unprivileged users
to debug a process that runs with real UID == 0, even when the
effective UID is that of the user.  That is the point I have been
making repeatedly in this thread, and now I am tired of making it.

Even if its only the saved uid, access to the process should be
prohibited.

Because of sloppy programming practices, left over "capabilities" (such
as file descriptors, privileged sockets, cached "secret" data) can be
available in processes that relinquish all privileges.  That's why
we modified Solaris.  The change isn't restricted to set-uid processes;
processes that start out as root and call set*uid or set*gid are also
non-debuggable and can't core dump. (e.g., /bin/login when run from
a root daemon)

Casper


Current thread: