SunOS and shared libraries, security aspects

[Guy Harris]

>It seems, however, that Sun has again hacked together and included in
>their OS something without taking security aspects into account.  The
>uid != euid check is not enough in current Unix systems; some programs
>which are setuid set their euid to the uid to which they're suid under

Err, well, if it's set-uid, when it starts up its euid already *is* the
uid to which it's suid.  I don't think that's what you meant to say....

>and so the linker happily links in the user's own library

The libraries are mapped in before "main()" is called, so whether
LD_LIBRARY_PATH is ignored depends only on the settings of the effective
and real UID and GID at the time the program is initially started up,
and is independent of what the program does after that.  (Yes, I tried
it.)

>I tried to think of a few quick ways to exploit it and came up with only
>/bin/login -p sync (preserver environment), if sync is an account with no
>password and daemon id as a common convention is.

OK, so the problem is something quite different from what you were
saying it is.  The problem isn't that "/bin/login "set(s) (its) euid to
the uid to which it's suid", it's that, when invoked with the "-p" flag
it passes LD_LIBRARY_PATH (and possibly other dangerous environment
variables) through when it runs the login shell of an account with no
password and that has a reasonably-privileged user ID.  The fix ain't to
change "ld.so"s rules for when it should honor LD_LIBRARY_PATH, it's to
change "login" to be more selective about which environment variables
it'll pass through.