GNU bug report logs -
#68961
ASLR seems to be partially broken
Previous Next
To reply to this bug, email your comments to 68961 AT debbugs.gnu.org.
Toggle the display of automated, internal messages from the tracker.
Report forwarded
to
bug-guix <at> gnu.org
:
bug#68961
; Package
guix
.
(Tue, 06 Feb 2024 22:59:02 GMT)
Full text and
rfc822 format available.
Acknowledgement sent
to
Jonathan Brielmaier <jonathan.brielmaier <at> web.de>
:
New bug report received and forwarded. Copy sent to
bug-guix <at> gnu.org
.
(Tue, 06 Feb 2024 22:59:02 GMT)
Full text and
rfc822 format available.
Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):
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
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:
https://git.launchpad.net/~ubuntu-kernel/ubuntu/+source/linux/+git/noble/commit/?h=master-next&id=760c2b1fa1f5e95be1117bc7b80afb8441d4b002
~Jonathan
Information forwarded
to
bug-guix <at> gnu.org
:
bug#68961
; Package
guix
.
(Thu, 08 Feb 2024 12:40:02 GMT)
Full text and
rfc822 format available.
Message #8 received at 68961 <at> debbugs.gnu.org (full text, mbox):
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
This bug report was last modified 295 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.