ASLR seems to be partially broken

  • Open
  • quality assurance status badge
Details
2 participants
  • Jonathan Brielmaier
  • Liliana Marie Prikler
Owner
unassigned
Submitted by
Jonathan Brielmaier
Severity
normal
J
J
Jonathan Brielmaier wrote on 6 Feb 23:57 +0100
(address . bug-guix@gnu.org)
9d2a36ae-983d-44a2-94f7-8e6aff389a05@web.de
Hi,

I found today an interesting blog post about broken ASLR (Address Space
Layout Randomization) on Linux:

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:

~Jonathan
L
L
Liliana Marie Prikler wrote on 8 Feb 09:50 +0100
e008f0783cd437c74b815d20987af5a65501c854.camel@student.tugraz.at
Am Dienstag, dem 06.02.2024 um 23:57 +0100 schrieb Jonathan Brielmaier:
Toggle quote (36 lines)
> 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.

Toggle quote (9 lines)
> 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
?
Your comment

Commenting via the web interface is currently disabled.

To comment on this conversation send an email to 68961@debbugs.gnu.org

To respond to this issue using the mumi CLI, first switch to it
mumi current 68961
Then, you may apply the latest patchset in this issue (with sign off)
mumi am -- -s
Or, compose a reply to this issue
mumi compose
Or, send patches to this issue
mumi send-email *.patch