Loading shared libraries from a setuid program

[Joe Halpin]

I've been working my way through the "Linker and Libraries Guide", but
I'm not finding the answer I need. A pointer, slap upside the head,
etc would be welcome.

Is there some reason why a program running suid root would not use the
LD_LIBRARY_PATH to find a library?

In the specific case I'm working on, a suid root program runs a
shell script (not owned by root), which runs a second program (also
not owned by root).

The shell script has some debug output in it that says the result of
id is:

uid=100(nortel) gid=100(nortel) euid=0(root)

So, the shell script is running with an effective user id of root,
which is what I would have expected. It then runs a binary (not suid)
owned by nortel. This binary cannot find a shared library it depends
on. Before running the binary, the shell script runs ldd on it, and
produces the output

ldd ../bin/commissioningCfg =
librwtool.so.2 => (file not found)
libsocket.so.1 => /usr/lib/libsocket.so.1
libnsl.so.1 => /usr/lib/libnsl.so.1
libC.so.5 => /usr/lib/libC.so.5
libm.so.1 => /usr/lib/libm.so.1
libw.so.1 => /usr/lib/libw.so.1
libc.so.1 => /usr/lib/libc.so.1
libdl.so.1 => /usr/lib/libdl.so.1
libmp.so.2 => /usr/lib/libmp.so.2
/usr/platform/SUNW,Ultra-250/lib/libc_psr.so.1

However, librwtool.so.2 is, in fact, in a directory specified by the
LD_LIBRARY_PATH.

If the shell script is run from the command line as nortel, with
LD_LIBRARY_PATH set appropriately, it works fine.

All the above holds true if the -R linker option is used to specify a
runpath when linking, rather than using LD_LIBRARY_PATH.

I'd appreciate a pointer in the right direction.

Thanks

Joe

[Isaac Lin]

Joe Halpin wrote:

> I've been working my way through the "Linker and Libraries Guide", but
> I'm not finding the answer I need. A pointer, slap upside the head,
> etc would be welcome.
>
> Is there some reason why a program running suid root would not use the
> LD_LIBRARY_PATH to find a library?

It's a security hole, since the user can redefine LD_LIBRARY_PATH to point
to an evil version of the shared library. Thus LD_LIBRARY_PATH is not used
for setuid programs.

[John Hickin]

As Isaac says, it is a security hole. If running Linux there is a
work-around (man ldconfig); some versions of Solaris have a similar
work-around too.

Other work-arounds, not necessarily to your liking are:

- remove the setuid bit from the program file
- make the program file statically linked


Regards, John.

[Joe Halpin]

Isaac Lin <isaacl@nortelnetworks.com> writes:

> Joe Halpin wrote:

> > I've been working my way through the "Linker and Libraries Guide",
> > but I'm not finding the answer I need. A pointer, slap upside the
> > head, etc would be welcome.
> >
> > Is there some reason why a program running suid root would not use
> > the LD_LIBRARY_PATH to find a library?

>
> It's a security hole, since the user can redefine LD_LIBRARY_PATH to
> point to an evil version of the shared library. Thus LD_LIBRARY_PATH
> is not used for setuid programs.

Does this hold true as well when the -R linker option is used to
record the search path into the executable? It did the same thing
either way.

Joe

[Chris Mattern]

Joe Halpin wrote:

> I've been working my way through the "Linker and Libraries Guide", but
> I'm not finding the answer I need. A pointer, slap upside the head,
> etc would be welcome.
>
> Is there some reason why a program running suid root would not use the
> LD_LIBRARY_PATH to find a library?

Yes. It would allow anybody with authority to run the program to use
LD_LIBRARY_PATH to supply it subverted libraries and essentially
do anything he felt like. LD_LIBRARY_PATH is ignored for all
setuid programs in any modern flavor of UNIX.

Chris Mattern

[Nial]

Joe Halpin <jhalpin@nortelnetworks.com_.nospam> wrote in message news:<yxs7n0fqlzzf.fsf@nortelnetworks.com_.nospam> ...

man crle
option -s may be help to you

> I've been working my way through the "Linker and Libraries Guide", but
> I'm not finding the answer I need. A pointer, slap upside the head,
> etc would be welcome.
>
> Is there some reason why a program running suid root would not use the
> LD_LIBRARY_PATH to find a library?
>
> In the specific case I'm working on, a suid root program runs a
> shell script (not owned by root), which runs a second program (also
> not owned by root).
>
> The shell script has some debug output in it that says the result of
> id is:
>
> uid=100(nortel) gid=100(nortel) euid=0(root)
>
> So, the shell script is running with an effective user id of root,
> which is what I would have expected. It then runs a binary (not suid)
> owned by nortel. This binary cannot find a shared library it depends
> on. Before running the binary, the shell script runs ldd on it, and
> produces the output
>
> ldd ../bin/commissioningCfg =
> librwtool.so.2 => (file not found)
> libsocket.so.1 => /usr/lib/libsocket.so.1
> libnsl.so.1 => /usr/lib/libnsl.so.1
> libC.so.5 => /usr/lib/libC.so.5
> libm.so.1 => /usr/lib/libm.so.1
> libw.so.1 => /usr/lib/libw.so.1
> libc.so.1 => /usr/lib/libc.so.1
> libdl.so.1 => /usr/lib/libdl.so.1
> libmp.so.2 => /usr/lib/libmp.so.2
> /usr/platform/SUNW,Ultra-250/lib/libc_psr.so.1
>
> However, librwtool.so.2 is, in fact, in a directory specified by the
> LD_LIBRARY_PATH.
>
> If the shell script is run from the command line as nortel, with
> LD_LIBRARY_PATH set appropriately, it works fine.
>
> All the above holds true if the -R linker option is used to specify a
> runpath when linking, rather than using LD_LIBRARY_PATH.
>
> I'd appreciate a pointer in the right direction.
>
> Thanks
>
> Joe

[Casper H.S. Dik]

"John Hickin" <hickin@nortelnetworks.com> writes:

>As Isaac says, it is a security hole. If running Linux there is a
>work-around (man ldconfig); some versions of Solaris have a similar
>work-around too.

The "workaround" is crle.

>Other work-arounds, not necessarily to your liking are:

>- remove the setuid bit from the program file
>- make the program file statically linked

Neither might be options; the solution is to add the directory
where the library is to be found to the compiled in runpath by
specifying the -R flag when linking.

Casper
--
Expressed in this posting are my opinions. They are in no way related
to opinions held by my employer, Sun Microsystems.
Statements on Sun products included here are not gospel and may
be fiction rather than truth.