xfce.org/lunar-linux.org server nearly hacked

[Auke Kok]

Brian J. Tarricone wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Auke Kok wrote:
> 
>>Brian J. Tarricone wrote:
>>
>>
>>>Auke Kok wrote:
>>>
>>>
>>>>- Mount /tmp and world-writeable mountpoints with noexec, this will stop
>>>>most OOTB exploits immediately as the rootkit or backdoor will fail to
>>>>execute
>>>
>>>Though this really doesn't help all *that* much, since the attacker can
>>>just do:
>>>
>>>$ /lib/libc.so.6 /tmp/really_bad_program
>>>
>>>And voila - you can execute stuff on /tmp.
>>
>>Supposedly that doesn't work anymore, with my systems I don't get that
>>result even:
>>
>>/tmp # /lib/libc.so.6 /tmp/ls
>>GNU C Library stable release version 2.3.2, by Roland McGrath et al.
>>Copyright (C) 2003 Free Software Foundation, Inc.
>>This is free software; see the source for copying conditions.
>>There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A
>>PARTICULAR PURPOSE.
>>Available extensions:
>>        GNU libio by Per Bothner
>>        crypt add-on version 2.1 by Michael Glad and others
>>        linuxthreads-0.10 by Xavier Leroy
>>        BIND-8.2.3-T5B
>>        libthread_db work sponsored by Alpha Processor Inc
>>Report bugs using the `glibcbug' script to <bugs at gnu.org>.
>>/tmp #
>>
>>and supposedly it's the linker libdl.so that should work according to refs:
>>
>>/tmp # /lib/ld-linux.so.2 /tmp/ls
>>/tmp/ls: error while loading shared libraries: /tmp/ls: failed to map
>>segment from shared object: Operation not permitted
>>/tmp #
>>
>>no go for executing binaries thus, unless I'm missing another way around
>>that. I'd sure like to hear about it ;^)
> 
> 
> Gah, yeah, I meant ld-linux.  My mistake.  And you're right, it doesn't
> appear to work on volumes mounted noexec, though I'm pretty sure it used
> to at some point.
> 
> On the other hand, you can still run perl scripts on noexec volumes, and
> considering that you can do a ridiculous amount of things with perl
> (such as a network-accessible daemon that spawns backdoor shells), I'd
> say that still represents a security risk, though admittedly not as much
> of one.
> 
> I suppose this whole point is moot if someone's managed to compromise a
> real user's account, though, since they could just run binaries from
> that user's home directory.  I imagine not too many hosts (where people
> do useful work, anyway) have /home mounted noexec.
> 
> 
>>>Out of idle curiosity, can
>>>you safely remove the execute bit on libc and have a functioning system?
>>>I know in general on Linux you don't need to make shared libs
>>>executable, but I dunno, libc may be an exception.
>>
>>only to have 'ldd' functioning AFAIK, but I'm not gonna try this on a
>>live system just yet, maybe with something safe first ;^)
> 
> Yeah... not something you want to test out on a production system ^_^.
> And since the ld-linux trick doesn't work on noexec mounts, there
> probably isn't much (any?) benefit.

1) grsec also prevents mmap-ing through PAX on noexec mounted devices
2) the feature apparently made it into 2.6 and recent 2.4 kernels too

Indeed, a perl script (or even bash =^)) could replace this 
functionality nowadays ... scary. Lets just keep everything tight and be 
anal about what we run on the http server ;^)

btw looks like indeed you can make all .so's a-x... interesting. I've 
tested most stuff except libc/libdl itself.

sofar