GNU bug report logs - #68961
ASLR seems to be partially broken

Previous Next

Package: guix;

Reported by: Jonathan Brielmaier <jonathan.brielmaier <at> web.de>

Date: Tue, 6 Feb 2024 22:59:02 UTC

Severity: normal

To reply to this bug, email your comments to 68961 AT debbugs.gnu.org.

Toggle the display of automated, internal messages from the tracker.

View this report as an mbox folder, status mbox, maintainer mbox


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):

From: Jonathan Brielmaier <jonathan.brielmaier <at> web.de>
To: bug-guix <at> gnu.org
Subject: ASLR seems to be partially broken
Date: Tue, 6 Feb 2024 23:57:53 +0100
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):

From: Liliana Marie Prikler <liliana.prikler <at> student.tugraz.at>
To: Jonathan Brielmaier <jonathan.brielmaier <at> web.de>, 68961 <at> debbugs.gnu.org
Subject: Re: ASLR seems to be partially broken
Date: Thu, 08 Feb 2024 09:50:49 +0100
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 85 days ago.

Previous Next


GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.