linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: cerberus cerberus <aktiophi@gmail.com>
To: linux-kernel@vger.kernel.org
Subject: Randomize address space after each fork
Date: Wed, 31 Oct 2018 19:26:47 -0600	[thread overview]
Message-ID: <CAC_DqTA-5tMfRKV42EAUYiewTOAZMDjLpsNGrKeMKLOgGQ77zg@mail.gmail.com> (raw)

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!

                 reply	other threads:[~2018-11-01  1:27 UTC|newest]

Thread overview: [no followups] expand[flat|nested]  mbox.gz  Atom feed

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=CAC_DqTA-5tMfRKV42EAUYiewTOAZMDjLpsNGrKeMKLOgGQ77zg@mail.gmail.com \
    --to=aktiophi@gmail.com \
    --cc=linux-kernel@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).