linux-kernel - Re: [PATCH] ASLRv3: randomize_va_space=3 preventing offset2lib attack

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>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Fri, 12 Dec 2014 17:32:44 +0100
From:	Hector Marco <hecmargi@....es>
To:	Kees Cook <keescook@...omium.org>
CC:	linux-kernel@...r.kernel.org,
	Andy Lutomirski <luto@...capital.net>,
	David Daney <ddaney.cavm@...il.com>,
	Jiri Kosina <jkosina@...e.cz>,
	Arun Chandran <achandran@...sta.com>,
	Hanno Böck <hanno@...eck.de>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Thomas Gleixner <tglx@...utronix.de>,
	Ingo Molnar <mingo@...hat.com>,
	"H. Peter Anvin" <hpa@...or.com>,
	Russell King - ARM Linux <linux@....linux.org.uk>,
	Catalin Marinas <catalin.marinas@....com>,
	Will Deacon <will.deacon@....com>,
	Oleg Nesterov <oleg@...hat.com>,
	Heiko Carstens <heiko.carstens@...ibm.com>,
	Martin Schwidefsky <schwidefsky@...ibm.com>,
	Anton Blanchard <anton@...ba.org>,
	Benjamin Herrenschmidt <benh@...nel.crashing.org>,
	Christian Borntraeger <borntraeger@...ibm.com>,
	Reno Robert <renorobert@...il.com>,
	Ismael Ripoll <iripoll@...ca.upv.es>
Subject: Re: [PATCH] ASLRv3: randomize_va_space=3 preventing offset2lib attack

Hello,

I agree. I don't think a new randomization mode will be needed, just fix
the current randomize_va_space=2. Said other way: fixing the offset2lib
will not break any current program and so, no need to add additional
configuration options. May be we shall wait for some inputs
from the list (may be we are missing something).


Regarding to VDSO, definitively, is not randomized enough in 64bits.
Brute force attacks would be pretty fast even from the network.
I have identified the bug and seems quite easy to fix it.

On 32bit systems, this is not a issue because it is mapped in the
mmap area. In order to fix the VDSO on 64bit, the following
considerations shall
be discussed:


Performance:
    It seems (reading the kernel comments) that the random allocation
    algorithm tries to place the VDSO in the same PTE than the stack.
    But since the permissions of the stack and the VDSO are different
    it seems that are getting right the opposite.

    Effectively VDSO shall be correctly randomized because it contains
    enough useful exploitable stuff.

    I think that the possible solution is follow the x86_32 approach
    which consist on map the VDSO in the mmap area.

    It would be better fix VDSO in a different patch ? I can send a
    patch which fixes the VDSO on 64 bit.



Regards,
Hector Marco.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/