xfce.org/lunar-linux.org server nearly hacked
alexander.toresson at gmail.com
Thu Jul 28 01:17:47 CEST 2005
I've got a spare debian install which I run in qemu for situations like this :)
That way I don't have to care if I fuck up the system (I keep a backup
of the 2gb hd image).
# cd /lib
# chown a-x *.so*
# ls -al
-bash: /bin/ls: Permission Denied
# chown a+x *.so*
-bash: /bin/chown: Permission Denied
Summary: not a good idea :)
Regards, Alexander Toresson
On 7/27/05, Auke Kok <sofar at lunar-linux.org> wrote:
> 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
> >>>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.
> Xfce mailing list
> Xfce at xfce.org
More information about the Xfce