SunOS and shared libraries, security aspects

[Jyrki Kuoppala]

In article <3991 at auspex.auspex.com>, guy at auspex (Guy Harris) writes:
>>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....

Oops, sorry, of course I meant to say that some programs set their
real uid to the euid (the uid to which they're suid under), and this
is the problem.

>>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.)

Yes, but some programs start _other_ programs after setting uid to
euid; in this case, euid == uid and when this other program (like when
/bin/login starts the login shell /bin/sync) is loaded the
LD_LIBRARY_PATH is used.  This is the problem, sorry if I was a bit
unclear.

>>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.

Yes; and change all those dozen's of other programs (like the ones
which come from the Usenet) to also unsetenv LD_LIBRARY_PATH when they
do setuid(geteuid()).  No, I don't really know if this is common but
it's hard to know exactly what programs do this (especially for SunOS
binary users) and so the problem is hard to solve this way.

And I haven't figured out a good way to change LD_LIBRARY_PATH
semantics.  Perhaps a kludge to the setuid() function which unsetenv's
LD_LIBRARY_PATH when euid != uid and setuid() is used to set it to the
real uid ?  This would solve the problem in the general case, you
would just have to recompile (umm, with shared libraries you wouldn't
have to recompile, something useful about them too ;-)

However, the security aspects of LD_LIBRARY_PATH should be documented
(well, I don't know if they are, I haven't read all the SunOS
manuals).

So, anyone see somthing wrong with the solution: We write a kludged
setuid() to unsetenv LD_LIBRARY_PATH and distribute it with
instructions of how to install it in your machine's shared library.
We also find out which staticcally-linked programs have the problem
and instruct users to recompile them and distribute fixed binaries for
binary-only users.

//Jyrki

[ I vote for creation of a newsgroup called comp.unix.wizards ]