Re: Improving security for pkgsrc

[Joerg Sonnenberger <joerg%britannica.bec.de@localhost>]

On Sun, Jul 19, 2015 at 01:50:36AM +0200, Pierre Pronchery wrote:
> 			So,
> 
> On 07/18/15 21:56, Joerg Sonnenberger wrote:
> > On Sat, Jul 18, 2015 at 07:14:36PM +0200, Pierre Pronchery wrote:
> >> I know that it does not mean it is a silver bullet, but it seems to be
> >> more than mature, and a significant number of community- and
> >> enterprise-driven projects have embraced it. And then, most are using
> >> more aggressive versions even. Personally, I consider it
> >> state-of-the-art, and we should at least provide the option.
> > 
> > It is not state-of-the-art, far from it. That would be control flow
> > integrity. The problem with stack smashing protection are two fold:
> 
> It is the level of development (as of a technique) reached years ago as
> a result of the common methodologies employed.
> https://en.wikipedia.org/wiki/State-of-the-art

I know what state-of-the-art means, thanks. The goal of SSP is to
prevent manipulation of the return address. Other techniques like CFI
are significantly better at fulfilling that goal. As such, SSP is not
state-of-the-art.

> > (1) As soon as more than one buffer in a function is present, it can
> > only effectively protect overflows in one of them.
> 
> It protects overflows of every buffer. Of course all except one are not
> in the direct vicinity of the return address, but is does not matter:
> overflowing any one of these buffers is enough to trigger an exploit,
> but then the canary as well. So yes, it does help.

No, this is plainly wrong. There is only a single canary and it is often
not even directly after a buffer. So a single byte overflow of the
top-most buffer is often not detected in case of padding nor is any
single byte overflow of buffers lower than this. The detection of the
buffer overflow also assumes that the buffer is overwritten completely
-- if you can access arbitrary offsets, it doesn't help at all.

> > (2) Even assuming the most dumb attack vector, repeated tries can easily
> > defeat it.
> 
> Possibly, but not easily. And even then, if you are trying to exploit a
> system service, you have one shot until it will stop running, dump core
> and the admin will get an e-mail about it. This is a typical situation
> for remote attacks; local attacks have a lot of easier attack vectors
> available. So yes, it does help.

If you try to attack OpenSSH for example, it is that easy. The daemon
will spawn you a nice new process to try and from the birthday paradox
you can expect 64k to yield a matching canary. Such a scenario applies
to many other daemons as well.

> > Now I am not arguing that it doesn't make a certain class of attacks
> > more harder. But the main point is that it is at most security in depth.
> > It does not prevent exploits, it just makes them harder.
> 
> It *mitigates* them.

Privilege separation, when done correctly, mitigates an exploit.
Stack protector as mentioned above doesn't for many deployment
scenarios. Once the canary has been guessed, the exploit is as
devastating as originally.

Joerg