Re: Long Exim break-in analysis
On Thu, Dec 23, 2010 at 12:54:44PM +0100, Bernhard R. Link wrote:
> * Bastian Blank <email@example.com> [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
> 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
For native code, they usualy rely on the possiblity to do executable
> > 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
Lets try it. As the kernel explicitely disallows suid scripts for
security reasons, it needs to do more checks, not less.
You can't evaluate a man by logic alone.
-- McCoy, "I, Mudd", stardate 4513.3