Re: Debian Stable server hacked

[Adam Majer <adamm@galacticasoftware.com>]

On Fri, Aug 22, 2003 at 10:32:27AM -0400, Matt Zimmerman wrote:
> On Wed, Aug 20, 2003 at 05:23:30PM +0200, Adam ENDRODI wrote:
> 
> > > You don't need an executable stack to get control of execution, you only
> > > need to be able to change the instruction pointer, which is stored on
> > > the stack (as data).
> > 
> > PaX is not just about non-executable address regions, but address space
> > randomization.  In my understanding, the attacker just doesn't know what
> > he should modify the IP to.  Given this, are you certain that only a
> > narrow range of exploits ("common implementations") can be killed via PaX?
> 
> It is often the case that the attacker doesn't know the exact location of
> structures in memory; there are techniques for finding out.  I'm sure that
> the authors of PaX do not misrepresent it as complete protection.

Sure, that's why you have the ACL for the *just in case* scenario.
And yes, that includes a restrictive default ACL just in case someone
manages to go around the application specific ACL.

For instance, let's look at a very simple ACL I have for MySQL:

/usr/sbin/mysqld oX {
        /usr/share/mysql r
        /var/lib/mysql rw
        /var/log/mysql a
        / h

        -CAP_ALL

        RES_CRASH 1 10m

        connect {
                disabled
        }

        bind {
                disabled
        }
}

So that everything is hidden except for 3 paths. And all those
are restricted somewhat. The only writable path is the mysql database path.
You cannot execute stuff there. Sure, I don't think that Grsec prevents
me from dynamically loaded an .so and running it, *BUT* then all of that
code gets executed in mysqld so you are still stuck with this ACL.

I think there would have to be some hole in Grsec for one to allow
you to break out of this ACL.

Furthermore, the point of the ACL system is not only to restrict specific applications,
but to restrict the root user itself so that someone breaking into root,
even getting shell, will not be able to do much to /bin or /usr/bin or /lib
or even /etc since (at least I) have /etc read-only.

Hence I would have to say that Pax is a good deterrent for script-kiddies
but an ACL with Pax (like in Grsec) makes it difficult even for the
"best of them" (I hope :) he he

> It's pointless to argue about it; it's clear that PaX provides some value in
> protection against security vulnerabilities, and I think it's also clear
> that because it will break many existing applications, it is not suitable
> for use by default.  But there is no reason why a PaX-enabled kernel could
> not be provided as an option.  All it needs is someone willing to do the
> work (hint, hint).

I would *not* recommend a Grsec or pax system for Desktop by default :)
I'm not even sure if it would be good to include it in Debian. IMHO, it is
best to build a monolithic kernel and disable all the options you don't
need for a specific machine when you patch the kernel with Grsec or pax.


- Adam