Re: Improving security for pkgsrc

[Pierre Pronchery <khorben%defora.org@localhost>]

			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

> (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.

> (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.

> 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.

>>>> 2. Building position-independent code:
>>>>
>>>>   +_GCC_CFLAGS+=  -fPIC
>>>>   +_GCC_LDFLAGS+= -Wl,-pie
>>>
>>> This is not the correct way to create position independent binaries.
>>
>> Would you care mentioning what the correct way is then?
>> As a matter of fact, like I said, I have tested this to be working,
>> except for the issue I mentioned.
> 
> The correct way is to compile *and* link with -fPIE as documented. There
> are real differences for code generation purposes like whether access to
> the GOT can be bypassed. For linking, -Wl,-pie will result in the wrong
> CRT routines to be used.

Ok, thank you, I will investigate in this direction.

>>>> 3. Linking with RELRO by default:
>>>>
>>>>   +_GCC_LDFLAGS+= -Wl,-z,relro
>>>>
>>>> I am less familiar with this one, which OpenBSD has been advocating
>>>> for a while now:
>>>> http://undeadly.org/cgi?action=article&sid=20030126143902
>>>> (and in some slides from theo)
>>>
>>> This one has major performance implementations and requires support from
>>> the system for proper behavior.
>>
>> Would you have pointers for this too?
> 
> Most trivially, relro as implemented by OpenBSD disables lazy binding.

Alright, I will also have a look at this.

HTH,
-- 
khorben