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