[gentoo-hardened] Question about ASLR

[gentoo-hardened] Question about ASLR

[François]

[-- Attachment #1: Type: text/plain, Size: 1063 bytes --]

Hi,

this is my first message here, I hope I'm not off-topic!

I've been reading [1], and tried on my gentoo system:

fser@regal /tmp$ ./aslr-test-without
main @ 0x4005da
doit @ 0x40059b
fser@regal /tmp$ ./aslr-test-without
main @ 0x4005da
doit @ 0x40059b
fser@regal /tmp$ ./aslr-test-without
main @ 0x4005da
doit @ 0x40059b


and

fser@regal /tmp$ ./aslr-test-withpie
main @ 0x468f410820
doit @ 0x468f4107e1
fser@regal /tmp$ ./aslr-test-withpie
main @ 0x6d8a0f9820
doit @ 0x6d8a0f97e1
fser@regal /tmp$ ./aslr-test-withpie
main @ 0x33eb5d8820
doit @ 0x33eb5d87e1
fser@regal /tmp$ ./aslr-test-withpie
main @ 0x769c4a5820
doit @ 0x769c4a57e1

I was under the impression that ASLR was enforced by the kernel, when
creating a new context for a process.
Reading the description of [1], I was expecting the adress of main (at
least) to be different.

Can someone explain me this behavior?

Thank you!


[1]
https://wiki.gentoo.org/wiki/Hardened/PaX_Quickstart#Address_Space_Layout_Randomization_.28ASLR.29

--
François


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

Re: [gentoo-hardened] Question about ASLR

[Sven Vermeulen]

On Thu, Aug 27, 2015 at 03:02:59PM +0200, François wrote:
> this is my first message here, I hope I'm not off-topic!
> 
> I've been reading [1], and tried on my gentoo system:
> 
> fser@regal /tmp$ ./aslr-test-without
> main @ 0x4005da
> doit @ 0x40059b
> fser@regal /tmp$ ./aslr-test-without
> main @ 0x4005da
> doit @ 0x40059b
> fser@regal /tmp$ ./aslr-test-without
> main @ 0x4005da
> doit @ 0x40059b
> 
> 
> and
> 
> fser@regal /tmp$ ./aslr-test-withpie
> main @ 0x468f410820
> doit @ 0x468f4107e1
> fser@regal /tmp$ ./aslr-test-withpie
> main @ 0x6d8a0f9820
> doit @ 0x6d8a0f97e1
> fser@regal /tmp$ ./aslr-test-withpie
> main @ 0x33eb5d8820
> doit @ 0x33eb5d87e1
> fser@regal /tmp$ ./aslr-test-withpie
> main @ 0x769c4a5820
> doit @ 0x769c4a57e1
> 
> I was under the impression that ASLR was enforced by the kernel, when
> creating a new context for a process.
> Reading the description of [1], I was expecting the adress of main (at
> least) to be different.
> 
> Can someone explain me this behavior?

ASLR only works properly with binaries that use Position Independent Code. That
means that the generated machine code does not hardcode any (virtual)
addresses, instead uses relative addressing. Some information about this is
at
https://wiki.gentoo.org/wiki/Hardened/Introduction_to_Position_Independent_Code
but the page can benefit from some clean-ups and editing.

With ASLR, applications are given a random base address. With non-PIC
applications, this doesn't matter as the base address is hardly used. The
code has hardcoded locations anyway, so the (randomized) base address is
ignored.

Wkr,
	Sven Vermeulen

Re: [gentoo-hardened] Question about ASLR

[François]

Thanks for your answer (sorry to respond that late). It actually makes
sense, I thought there was some *magic* possible.
This proves once again how fragile security can be (I'm thinking about
compilated distributions, where kernel can be hardened but the
compilation process must also be taken care of).

Thanks again
--
François


On 27 August 2015 at 19:42, Sven Vermeulen <swift@gentoo.org> wrote:
> On Thu, Aug 27, 2015 at 03:02:59PM +0200, François wrote:
>> this is my first message here, I hope I'm not off-topic!
>>
>> I've been reading [1], and tried on my gentoo system:
>>
>> fser@regal /tmp$ ./aslr-test-without
>> main @ 0x4005da
>> doit @ 0x40059b
>> fser@regal /tmp$ ./aslr-test-without
>> main @ 0x4005da
>> doit @ 0x40059b
>> fser@regal /tmp$ ./aslr-test-without
>> main @ 0x4005da
>> doit @ 0x40059b
>>
>>
>> and
>>
>> fser@regal /tmp$ ./aslr-test-withpie
>> main @ 0x468f410820
>> doit @ 0x468f4107e1
>> fser@regal /tmp$ ./aslr-test-withpie
>> main @ 0x6d8a0f9820
>> doit @ 0x6d8a0f97e1
>> fser@regal /tmp$ ./aslr-test-withpie
>> main @ 0x33eb5d8820
>> doit @ 0x33eb5d87e1
>> fser@regal /tmp$ ./aslr-test-withpie
>> main @ 0x769c4a5820
>> doit @ 0x769c4a57e1
>>
>> I was under the impression that ASLR was enforced by the kernel, when
>> creating a new context for a process.
>> Reading the description of [1], I was expecting the adress of main (at
>> least) to be different.
>>
>> Can someone explain me this behavior?
>
> ASLR only works properly with binaries that use Position Independent Code. That
> means that the generated machine code does not hardcode any (virtual)
> addresses, instead uses relative addressing. Some information about this is
> at
> https://wiki.gentoo.org/wiki/Hardened/Introduction_to_Position_Independent_Code
> but the page can benefit from some clean-ups and editing.
>
> With ASLR, applications are given a random base address. With non-PIC
> applications, this doesn't matter as the base address is hardly used. The
> code has hardcoded locations anyway, so the (randomized) base address is
> ignored.
>
> Wkr,
>         Sven Vermeulen
>

Re: [gentoo-hardened] Question about ASLR

[PaX Team]

On 30 Aug 2015 at 21:54, François wrote:

> Thanks for your answer (sorry to respond that late). It actually makes
> sense, I thought there was some *magic* possible.

i wouldn't call it magic but PaX used to provide RANDEXEC:

  https://pax.grsecurity.net/docs/randexec.txt

Re: [gentoo-hardened] Question about ASLR

[René Rhéaume]

2015-09-07 10:41 GMT-04:00 PaX Team <pageexec@freemail.hu>:
>
> On 30 Aug 2015 at 21:54, François wrote:
>
> > Thanks for your answer (sorry to respond that late). It actually makes
> > sense, I thought there was some *magic* possible.
>
> i wouldn't call it magic but PaX used to provide RANDEXEC:
>
>   https://pax.grsecurity.net/docs/randexec.txt

Is RANDEXEC abandoned because it could not be ported to other architectures?

Re: [gentoo-hardened] Question about ASLR

[PaX Team]

On 7 Sep 2015 at 11:06, René Rhéaume wrote:

> 2015-09-07 10:41 GMT-04:00 PaX Team <pageexec@freemail.hu>:
> > i wouldn't call it magic but PaX used to provide RANDEXEC:
> >
> >   https://pax.grsecurity.net/docs/randexec.txt
>
> Is RANDEXEC abandoned because it could not be ported to other architectures?

no, portability isn't a concern in general (if it were, we'd have removed
half the features already ;). rather, the underlying code was too complex
to maintain after a while (IIRC, it's become much harder with the 2.6 kernel
series) and the benefits weren't enough to justify the costs (e.g., false
positives, performance impact).