| 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: Fri, 19 Dec 2014 15:53:54 -0800 From: Andy Lutomirski <luto@...capital.net> To: Hector Marco <hecmargi@....es>, Cyrill Gorcunov <gorcunov@...nvz.org>, Pavel Emelyanov <xemul@...allels.com> Cc: Catalin Marinas <catalin.marinas@....com>, Heiko Carstens <heiko.carstens@...ibm.com>, Oleg Nesterov <oleg@...hat.com>, Ingo Molnar <mingo@...hat.com>, Anton Blanchard <anton@...ba.org>, Jiri Kosina <jkosina@...e.cz>, Russell King - ARM Linux <linux@....linux.org.uk>, "H. Peter Anvin" <hpa@...or.com>, David Daney <ddaney.cavm@...il.com>, Andrew Morton <akpm@...ux-foundation.org>, Arun Chandran <achandran@...sta.com>, "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>, Martin Schwidefsky <schwidefsky@...ibm.com>, Ismael Ripoll <iripoll@...ca.upv.es>, Christian Borntraeger <borntraeger@...ibm.com>, Thomas Gleixner <tglx@...utronix.de>, Hanno Böck <hanno@...eck.de>, Will Deacon <will.deacon@....com>, Benjamin Herrenschmidt <benh@...nel.crashing.org>, Kees Cook <keescook@...omium.org>, Reno Robert <renorobert@...il.com> Subject: Re: [PATCH] ASLRv3: randomize_va_space=3 preventing offset2lib attack On Fri, Dec 19, 2014 at 2:11 PM, Andy Lutomirski <luto@...capital.net> wrote: > On Fri, Dec 19, 2014 at 2:04 PM, Hector Marco <hecmargi@....es> wrote: >> >> >> El 12/12/14 a las 18:17, Andy Lutomirski escribió: >> >>> On Dec 12, 2014 8:33 AM, "Hector Marco" <hecmargi@....es> wrote: >>>> >>>> >>>> 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. >>> >>> >>> The comment is wrong. It means PTE table. >>> >>>> But since the permissions of the stack and the VDSO are different >>>> it seems that are getting right the opposite. >>> >>> >>> Permissions have page granularity, so this isn't a problem. >>> >>>> >>>> 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. >>>> >>> >>> What are the considerations for 64-bit memory layout? I haven't >>> touched it because I don't want to break userspace, but I don't know >>> what to be careful about. >>> >>> --Andy >> >> >> I don't think that mapping the VDSO in the mmap area breaks the >> userspace. Actually, this is already happening with the current >> implementation. You can see it by running: >> >> setarch x86_64 -R cat /proc/self/maps >> > > Hmm. So apparently we even switch which side of the stack the vdso is > on depending on the randomization setting. > >> >> Do this break the userspace in some way ? >> >> >> Regarding the solution to the offset2lib it seems that placing the >> executable in a different memory region area could increase the >> number of pages for the pages table (because it is more spread). >> We should consider this before fixing the current implementation >> (randomize_va_space=2). >> >> I guess that the current implementation places the PIE executable in >> the mmap base area jointly with the libraries in an attempt to reduce >> the size of the page table. >> >> Therefore, I can fix the current implementation (maintaining the >> randomize_va_space=2) by moving the PIE executable from the mmap base >> area to another one for x86*, ARM* and MIPS (as s390 and PowerPC do). >> But we shall agree that this increment in the page table is not a >> issue. Otherwise, the randomize_va_space=3 shall be considered. > > Wrt the vdso itself, though, there is an extra consideration: CRIU. I > *think* that the CRIU vdso proxying scheme will work even if the vdso > changes sizes and is adjacent to other mappings. Cyrill and/or Pavel, > am I right? > > I'm not fundamentally opposed to mapping the vdso just like any other > shared library. I still think that we should have an extra-strong > randomization mode in which all the libraries are randomized wrt each > other, though. For many applications, the extra page table cost will > be negligible. This is stupid. The vdso randomization is just buggy, plain and simple. Patch coming. > > --Andy > >> >> >> Hector Marco. >> >>> >>>> >>>> >>>> Regards, >>>> Hector Marco. > > > > -- > Andy Lutomirski > AMA Capital Management, LLC -- Andy Lutomirski AMA Capital Management, LLC -- 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/
Powered by blists - more mailing lists