lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<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

Powered by Openwall GNU/*/Linux Powered by OpenVZ