* bug#68961: ASLR seems to be partially broken
2024-02-06 22:57 bug#68961: ASLR seems to be partially broken Jonathan Brielmaier via Bug reports for GNU Guix
@ 2024-02-08 8:50 ` Liliana Marie Prikler
0 siblings, 0 replies; 2+ messages in thread
From: Liliana Marie Prikler @ 2024-02-08 8:50 UTC (permalink / raw)
To: Jonathan Brielmaier, 68961
Am Dienstag, dem 06.02.2024 um 23:57 +0100 schrieb Jonathan Brielmaier:
> Hi,
>
> I found today an interesting blog post about broken ASLR (Address
> Space
> Layout Randomization) on Linux:
> https://zolutal.github.io/aslrnt/
>
> Curious if this is also a problem on Guix System I did a quick test.
>
> ```
> $ cat aslr.py
> from subprocess import check_output
> result = 0x0
> for _ in range(0,1000):
> out = check_output("cat /proc/self/maps | grep libc | head -n1",
> shell=True).decode()
> base_address = int(out.split('-')[0], 16)
> result |= base_address
> print('libc: ' + hex(result))
>
> resultld = 0x0
> for _ in range(0,1000):
> out = check_output("cat /proc/self/maps | grep ld-linux | head
> -n1", shell=True).decode()
> base_address = int(out.split('-')[0], 16)
> resultld |= base_address
> print('ld-linux: ' + hex(resultld))
> ```
>
> Running this on x86_64 system of mine results on two systems in:
> libc: 0x7ffffffa9000
> ld-linux: 0x7ffffffff000
>
> On the third system it prints:
> libc: 0x7ffffffff000
> ld-linux: 0x7ffffffff000
On my machine, this also prints 0x7ffffffff000. Perhaps 1000 runs are
not good enough to get truly random results with some RNGs. Note that
we do have 51 bits of randomness here – perhaps not ideal, but afaik
the best we can do without breaking alignment.
> For 32bit it looks even worse (not sure if it's correct to test it
> like
> this):
> $ guix shell --system=i686-linux coreutils python -- python3 aslr.py
> libc: 0xf7800000
> ld-linux: 0xf7fff000
>
> Not sure what we should do here. There seem to be some a kernel patch
> for Ubuntu available:
For 32 bit, try
```
from subprocess import check_output
result = 0xffffffff
for _ in range(0,1000):
out = check_output("cat /proc/self/maps | grep libc | head -n1",
shell=True).decode()
base_address = int(out.split('-')[0], 16)
result &= base_address
print('libc: ' + hex(result))
resultld = 0xffffffff
for _ in range(0,1000):
out = check_output("cat /proc/self/maps | grep ld-linux | head -
n1", shell=True).decode()
base_address = int(out.split('-')[0], 16)
resultld &= base_address
print('ld-linux: ' + hex(resultld))
from subprocess import check_output
result = 0xffffffff
for _ in range(0,1000):
out = check_output("cat /proc/self/maps | grep libc | head -n1",
shell=True).decode()
base_address = int(out.split('-')[0], 16)
result &= base_address
print('libc: ' + hex(result))
resultld = 0xffffffff
for _ in range(0,1000):
out = check_output("cat /proc/self/maps | grep ld-linux | head -
n1", shell=True).decode()
base_address = int(out.split('-')[0], 16)
resultld &= base_address
print('ld-linux: ' + hex(resultld))
```
instead. I get 0xf7c00000 for libc and 0xf7e00000 – meaning that the
first nibble is always the same, but more importantly, these are also
the addresses you'd get on each run. So I'm pretty sure that ASLR'nt
applies to our 32 bit builds.
Since this is a known bug in the Linux kernel, I'd like to check
whether there's a fix we can backport. We could of course also patch
our config aux-files like Ubuntu does in the meantime.
Cheers
^ permalink raw reply [flat|nested] 2+ messages in thread