tech-pkg archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: Improving security for pkgsrc



On Tue, Jul 21, 2015 at 01:05:42PM +0200, Pierre Pronchery wrote:
> 			Hi,
> 
> On 07/19/15 17:12, Joerg Sonnenberger wrote:
> > On Sun, Jul 19, 2015 at 01:50:36AM +0200, Pierre Pronchery wrote:
> >>> 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.
> 
> Mitigate:
> 1. (transitive) To reduce, lessen, or decrease.

Thanks for the dictionary. I have one too.

> Privilege separation is one technique to achieve this, which can be
> combined with a number of other techniques to further reduce the attack
> surface. A lot of bugs that would be exploitable fall short of actual
> code execution *because* one or more mitigation techniques help
> preventing it.

No, you are either confused or are unable to use proper terminology. A
technique that does *not* reduce the attack surface by your very
definition can not be called a mitigation. Privilege separation does
reduce the attack surface from running code as root to running code as
unprivileged user. It does not prevent an attack, but it reduces the
impact.

> Guessing the canary as you say typically requires another bug again,
> like an information leak. It makes the whole thing harder, more
> expensive for the attacker. Attackers do have a budget too. We are
> wasting ours here.

This is bullshit. Guessing the canary can literally be a brute force.
No other bug is needed. This is the same way attacks again bad ASLR can
be done etc. Whether the effective security is 32bit or 16bit is
somewhat ephemeral for this discussion. Stop calling it a code
mitigation technique. It is not. If anything, it is a hardening
technique. It makes it more difficult to exploit something successfully,
but it doesn't change the *impact* of such an exploit.

Joerg


Home | Main Index | Thread Index | Old Index