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: Tue, 24 Nov 2015 16:39:07 -0800 From: Andrew Morton <akpm@...ux-foundation.org> To: Daniel Cashman <dcashman@...roid.com> Cc: linux-kernel@...r.kernel.org, linux@....linux.org.uk, keescook@...omium.org, mingo@...nel.org, linux-arm-kernel@...ts.infradead.org, corbet@....net, dzickus@...hat.com, ebiederm@...ssion.com, xypron.glpk@....de, jpoimboe@...hat.com, kirill.shutemov@...ux.intel.com, n-horiguchi@...jp.nec.com, aarcange@...hat.com, mgorman@...e.de, tglx@...utronix.de, rientjes@...gle.com, linux-mm@...ck.org, linux-doc@...r.kernel.org, salyzyn@...roid.com, jeffv@...gle.com, nnk@...gle.com, catalin.marinas@....com, will.deacon@....com, hpa@...or.com, x86@...nel.org, hecmargi@....es, bp@...e.de, dcashman@...gle.com, Ralf Baechle <ralf@...ux-mips.org>, Benjamin Herrenschmidt <benh@...nel.crashing.org>, Heiko Carstens <heiko.carstens@...ibm.com>, Martin Schwidefsky <schwidefsky@...ibm.com> Subject: Re: [PATCH v3 0/4] Allow customizable random offset to mmap_base address. On Wed, 18 Nov 2015 15:20:04 -0800 Daniel Cashman <dcashman@...roid.com> wrote: > Address Space Layout Randomization (ASLR) provides a barrier to > exploitation of user-space processes in the presence of security > vulnerabilities by making it more difficult to find desired code/data > which could help an attack. This is done by adding a random offset to the > location of regions in the process address space, with a greater range of > potential offset values corresponding to better protection/a larger > search-space for brute force, but also to greater potential for > fragmentation. > > The offset added to the mmap_base address, which provides the basis for > the majority of the mappings for a process, is set once on process exec in > arch_pick_mmap_layout() and is done via hard-coded per-arch values, which > reflect, hopefully, the best compromise for all systems. The trade-off > between increased entropy in the offset value generation and the > corresponding increased variability in address space fragmentation is not > absolute, however, and some platforms may tolerate higher amounts of > entropy. This patch introduces both new Kconfig values and a sysctl > interface which may be used to change the amount of entropy used for > offset generation on a system. > > The direct motivation for this change was in response to the > libstagefright vulnerabilities that affected Android, specifically to > information provided by Google's project zero at: > > http://googleprojectzero.blogspot.com/2015/09/stagefrightened.html > > The attack presented therein, by Google's project zero, specifically > targeted the limited randomness used to generate the offset added to the > mmap_base address in order to craft a brute-force-based attack. > Concretely, the attack was against the mediaserver process, which was > limited to respawning every 5 seconds, on an arm device. The hard-coded 8 > bits used resulted in an average expected success rate of defeating the > mmap ASLR after just over 10 minutes (128 tries at 5 seconds a piece). > With this patch, and an accompanying increase in the entropy value to 16 > bits, the same attack would take an average expected time of over 45 hours > (32768 tries), which makes it both less feasible and more likely to be > noticed. > > The introduced Kconfig and sysctl options are limited by per-arch minimum > and maximum values, the minimum of which was chosen to match the current > hard-coded value and the maximum of which was chosen so as to give the > greatest flexibility without generating an invalid mmap_base address, > generally a 3-4 bits less than the number of bits in the user-space > accessible virtual address space. > > When decided whether or not to change the default value, a system > developer should consider that mmap_base address could be placed anywhere > up to 2^(value) bits away from the non-randomized location, which would > introduce variable-sized areas above and below the mmap_base address such > that the maximum vm_area_struct size may be reduced, preventing very large > allocations. Nice, thanks. mips, powerpc and s390 also implement arch_mmap_rnd(). Are there any special considerations here, or it just a matter of maintainers wiring it up and testing it? -- 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