[12376] in bugtraq
Re: Fix for ssh-1.2.27 symlink/bind problem
daemon@ATHENA.MIT.EDU (Casper Dik)
Fri Oct 29 12:01:31 1999
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Message-Id: <199910290934.LAA06193@romulus>
Date: Fri, 29 Oct 1999 11:34:30 +0200
Reply-To: Casper Dik <casper@HOLLAND.SUN.COM>
From: Casper Dik <casper@HOLLAND.SUN.COM>
X-To: Wietse Venema <wietse@PORCUPINE.ORG>
To: BUGTRAQ@SECURITYFOCUS.COM
In-Reply-To: Your message of "Wed, 27 Oct 1999 18:35:56 EDT."
<19991027223556.8299945AF6@spike.porcupine.org>
>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
