Re: Patch 0/6 virtual address space randomisation
On Thu, Jan 27, 2005 at 09:13:04PM +0100, Arjan van de Ven wrote: > On Thu, 2005-01-27 at 20:34 +0100, Julien TINNES wrote: > > > > > > Yeah, if it came from PaX the randomization would actually be useful. > > > Sorry, I've just woken up and already explained in another post. > > > > > > > Please, no hard feelings. > > > > Speaking about implementation of the non executable pages semantics on > > IA32, PaX and Exec-Shield are very different (well not that much since > > 2.6 in fact because PAGEEXEC is now "segmentation when I can"). > > But when it comes to ASLR it's pretty much the same thing. > > > > The only difference may be the (very small) randomization of the brk() > > managed heap on ET_EXEC (which is probably the more "hackish" feature of > > PaX ASLR) but it seems that Arjan is even going to propose a patch for > > that (Is this in ES too ?). > > Exec shield randomized brk() too yes. > However that is a both more dangerous and more invasive change to do > correctly (you have no idea how hard it is to get that right for > emacs...) so that's reserved for the second batch of patches once this > first batch is dealt with. Oh, so you mean that we can both get a more secure system, *and* make emacs stop working? A win-win situation! =) Regards: David Weinehall -- /) David Weinehall <[EMAIL PROTECTED]> /) Northern lights wander (\ // Maintainer of the v2.0 kernel // Dance across the winter sky // \) http://www.acc.umu.se/~tao/(/ Full colour fire (/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Patch 0/6 virtual address space randomisation
On Thu, 2005-01-27 at 20:34 +0100, Julien TINNES wrote: > > > > Yeah, if it came from PaX the randomization would actually be useful. > > Sorry, I've just woken up and already explained in another post. > > > > Please, no hard feelings. > > Speaking about implementation of the non executable pages semantics on > IA32, PaX and Exec-Shield are very different (well not that much since > 2.6 in fact because PAGEEXEC is now "segmentation when I can"). > But when it comes to ASLR it's pretty much the same thing. > > The only difference may be the (very small) randomization of the brk() > managed heap on ET_EXEC (which is probably the more "hackish" feature of > PaX ASLR) but it seems that Arjan is even going to propose a patch for > that (Is this in ES too ?). Exec shield randomized brk() too yes. However that is a both more dangerous and more invasive change to do correctly (you have no idea how hard it is to get that right for emacs...) so that's reserved for the second batch of patches once this first batch is dealt with. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Patch 0/6 virtual address space randomisation
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Julien TINNES wrote: > >> >> Yeah, if it came from PaX the randomization would actually be useful. >> Sorry, I've just woken up and already explained in another post. >> > > Please, no hard feelings. > > Speaking about implementation of the non executable pages semantics on > IA32, PaX and Exec-Shield are very different (well not that much since > 2.6 in fact because PAGEEXEC is now "segmentation when I can"). > But when it comes to ASLR it's pretty much the same thing. > > The only difference may be the (very small) randomization of the brk() > managed heap on ET_EXEC (which is probably the more "hackish" feature of > PaX ASLR) but it seems that Arjan is even going to propose a patch for > that (Is this in ES too ?). > > I think it's a great opportunity here to get the same basis for ASLR in > PaX and ES merged into the vanilla kernel. > If it's only a matter of changing the number of randomized bits in an > additional PaX patch, it's no problem! It's more important to have a > correct basis, focus on that. > I'm not at all familiar with the code, though PaX uses more fine-grained binary markings in PT_PAX_FLAGS (requires a patched binutils, though I guess a PaX system could just nuke PT_GNU_STACK from .load and replace it with PT_PAX_FLAGS). *shrug* . . . ok so I've hacked at PaX' source a few times for fun, but I forgot everything I saw, I swear. :) whatever, at this point I've lost interest, as I'm starting to wonder where my next meal will come from. - -- All content of all messages exchanged herein are left in the Public Domain, unless otherwise explicitly stated. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.0 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD4DBQFB+UeohDd4aOud5P8RAra3AJsEs0fJiQvqbp45ySUbUQT/TJkDRACYoYzq nzy0VdUXiT84DEzzkPDVVQ== =exFr -END PGP SIGNATURE- - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Patch 0/6 virtual address space randomisation
Yeah, if it came from PaX the randomization would actually be useful. Sorry, I've just woken up and already explained in another post. Please, no hard feelings. Speaking about implementation of the non executable pages semantics on IA32, PaX and Exec-Shield are very different (well not that much since 2.6 in fact because PAGEEXEC is now "segmentation when I can"). But when it comes to ASLR it's pretty much the same thing. The only difference may be the (very small) randomization of the brk() managed heap on ET_EXEC (which is probably the more "hackish" feature of PaX ASLR) but it seems that Arjan is even going to propose a patch for that (Is this in ES too ?). I think it's a great opportunity here to get the same basis for ASLR in PaX and ES merged into the vanilla kernel. If it's only a matter of changing the number of randomized bits in an additional PaX patch, it's no problem! It's more important to have a correct basis, focus on that. -- Julien TINNES - & france telecom - R&D Division/MAPS/NSS Research Engineer - Internet/Intranet Security GPG: C050 EF1A 2919 FD87 57C4 DEDD E778 A9F0 14B9 C7D6 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Patch 0/6 virtual address space randomisation
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Arjan van de Ven wrote: > On Thu, 2005-01-27 at 12:45 +0100, Julien TINNES wrote: > >>Arjan van de Ven wrote: >> >>>The randomisation patch series introduces infrastructure and functionality >>>that causes certain parts of a process' virtual address space to be >>>different for each invocation of the process. The purpose of this is to >>>raise the bar on buffer overflow exploits; full randomisation makes it not >>>possible to use absolute addresses in the exploit. >>> >> >>I think it is worth mentioning that this is part of PaX ASLR, but with >>some changes and simplification. > > > it actually came from Exec-Shield not PaX > Yeah, if it came from PaX the randomization would actually be useful. Sorry, I've just woken up and already explained in another post. [...] > > - > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to [EMAIL PROTECTED] > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ > - -- All content of all messages exchanged herein are left in the Public Domain, unless otherwise explicitly stated. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.0 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFB+SfwhDd4aOud5P8RArzvAJ91+7oeFvQyhfH5ovHkkWG7FQcazgCfchDA 4lxXXLmMA5PcZuICxoxnQGU= =oXcE -END PGP SIGNATURE- - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Patch 0/6 virtual address space randomisation
On Thu, 2005-01-27 at 12:45 +0100, Julien TINNES wrote: > Arjan van de Ven wrote: > > The randomisation patch series introduces infrastructure and functionality > > that causes certain parts of a process' virtual address space to be > > different for each invocation of the process. The purpose of this is to > > raise the bar on buffer overflow exploits; full randomisation makes it not > > possible to use absolute addresses in the exploit. > > > > I think it is worth mentioning that this is part of PaX ASLR, but with > some changes and simplification. it actually came from Exec-Shield not PaX > I have some questions about the changes: > > for RANDMMAP why doing randomization in mmap_base() and not in > arch_pick_mmap_layout? You miss a whole case here where legacy layout is > used. legacy layout will want a different randomisation; it'll come in a separate, incremental patch. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Patch 0/6 virtual address space randomisation
Arjan van de Ven wrote: The randomisation patch series introduces infrastructure and functionality that causes certain parts of a process' virtual address space to be different for each invocation of the process. The purpose of this is to raise the bar on buffer overflow exploits; full randomisation makes it not possible to use absolute addresses in the exploit. I think it is worth mentioning that this is part of PaX ASLR, but with some changes and simplification. I have some questions about the changes: for RANDMMAP why doing randomization in mmap_base() and not in arch_pick_mmap_layout? You miss a whole case here where legacy layout is used. -- Julien TINNES - & france telecom - R&D Division/MAPS/NSS Research Engineer - Internet/Intranet Security GPG: C050 EF1A 2919 FD87 57C4 DEDD E778 A9F0 14B9 C7D6 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Patch 0/6 virtual address space randomisation
The randomisation patch series introduces infrastructure and functionality that causes certain parts of a process' virtual address space to be different for each invocation of the process. The purpose of this is to raise the bar on buffer overflow exploits; full randomisation makes it not possible to use absolute addresses in the exploit. This first series only does a partial randomisation, future series will randomize other parts of the virtual address space as well. 01-sysctl-A0- introduce a sysctl to enable/disable 02-randomize-infrastructure - infrastructure helpers 03-PF_RANDOMIZE - per process flag to enable/disable 04-stack- start randomizing the stack pointer 05-mmap - start randomizing mmap addresses 06-default-enable - enable randomisation by default (for -mm testing only) This series does NOT randomize the brk() area and does not yet add support for PIE binaries. This I will leave to a next series; this one should first settle down. Signed-off-by: Arjan van de Ven <[EMAIL PROTECTED]> - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
