[<prev] [next>] [day] [month] [year] [list]
Message-ID: <CAC_DqTA-5tMfRKV42EAUYiewTOAZMDjLpsNGrKeMKLOgGQ77zg@mail.gmail.com>
Date: Wed, 31 Oct 2018 19:26:47 -0600
From: cerberus cerberus <aktiophi@...il.com>
To: linux-kernel@...r.kernel.org
Subject: Randomize address space after each fork
Randomize address space after each fork
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
I might be entirely wrong with what I write
and the solution proposed thereafter, yet I
want to raise awareness that with current linux
kernels it is possible to leak (at least) heap
addresses in an attempt to weaken address space
layout randomization. The listed example shows [1]
code, it completely identifies three bytes of
the heap memory mappings, that is enough to weaken
aslr in a way to make it unusable over time.
One idea is to disallow a process to use the
same addresses after a fork and randomize them
after each fork just as during execution stage,
this will render the attack unusable. I know
this sounds nuts but is most probably the most
straightforward way to fix the issue.
real mapping:
55b118238000-55b11827b000 rw-p [heap]
linux kernel leaking the addresses partial:
Discover first byte in offset
Try Offsets 10ffff to ffffff ...
Try Offsets 20ffff to ffffff ...
Offset 239000 Survived ...
Offset 24d000 Survived ...
Offset 251000 Survived ...
Offset 261000 Survived ...
Offset 27d000 Survived ...
Offset 281000 Survived ...
That's quite exact the heap start to end address.
My apologies for suggesting only the solution,
I'm too stupid to implement this in real life in,
i.e. linux itself :)
[1] testcase: https://www.exploit-db.com/exploits/45671/
(referring to version 4.4.0-116, x86_64)
Have a nice day!
Powered by blists - more mailing lists