Re: Long Exim break-in analysis
On Thu, Dec 23, 2010 at 12:54:44PM +0100, Bernhard R. Link wrote:
> * Bastian Blank <waldi@debian.org> [101222 11:30]:
> > On Wed, Dec 22, 2010 at 10:18:50AM +0100, Bernhard R. Link wrote:
> > > That said, having /tmp noexec,nosuid and /var nosuid will only make some
> > > script-kiddies slower and the more people use it the less it helps.
> > It is a start.
> I'd not call it a start. It is more little a pillow at the ground of the
> pit. It's nice to have if someone falls but only helps once it is
> already to late.
I like to hack appliances. And they try to defend against people with
login rights. noexec on the correct locations makes it a lot more
dificult to go on.
> > > And history
> > > show that there were often ways around noexec and nosuid and though many
> > > of the known ones should be closed by now,
> > Around noexec: not much, at least for real binaries.
> In the past there was the ld.so trick. That is said to be closed now.
The kernel just does not allow any executable mappings of files on
noexec filesystems.
> But I would make no bet that on a full desktop-system there is nothing
> that cane still be used to execute something (perhaps some of those
> start-programs-with-libraries already loaded tricks or things like
> that).
For native code, they usualy rely on the possiblity to do executable
mappings.
> > Around nosuid:
> > please show me.
> In the past there was perl-suid. I hope noone will do something stupid
> as that again. But then I was already quite perplex something like that
> existed.
Lets try it. As the kernel explicitely disallows suid scripts for
security reasons, it needs to do more checks, not less.
Bastian
--
You can't evaluate a man by logic alone.
-- McCoy, "I, Mudd", stardate 4513.3
Reply to: