* How to enable/disable security features on mmap() ? @ 2005-12-08 14:10 Emmanuel Fleury 2005-12-08 14:14 ` Arjan van de Ven 0 siblings, 1 reply; 19+ messages in thread From: Emmanuel Fleury @ 2005-12-08 14:10 UTC (permalink / raw) To: Linux Kernel Hi, For educational purpose (I'm teaching software security) I would like to be able to compile several kernels with or without features such as: * Non-executable stack * Stack address randomization * Environment address randomization (char **envp) * Dynamic library randomization (cat /proc/self/map) The idea is to run these kernels in UML mode in order for the students to complete their exercises and to raise the security level as long as the course is going further. Just right now I'm using old versions of Distributions and this is not really satisfactory (because the compilers have evolved). So, is there a way to do such thing easily, or should I write patches by myself ? Regards -- Emmanuel Fleury <Sonium> someone speak python here? <lucky> HHHHHSSSSSHSSS <lucky> SSSSS <Sonium> the programming language -- http://bash.org/ ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: How to enable/disable security features on mmap() ? 2005-12-08 14:10 How to enable/disable security features on mmap() ? Emmanuel Fleury @ 2005-12-08 14:14 ` Arjan van de Ven 2005-12-08 14:21 ` Emmanuel Fleury 0 siblings, 1 reply; 19+ messages in thread From: Arjan van de Ven @ 2005-12-08 14:14 UTC (permalink / raw) To: Emmanuel Fleury; +Cc: Linux Kernel On Thu, 2005-12-08 at 15:10 +0100, Emmanuel Fleury wrote: > Hi, > > For educational purpose (I'm teaching software security) I would like to > be able to compile several kernels with or without features such as: > > * Non-executable stack > * Stack address randomization > * Environment address randomization (char **envp) > * Dynamic library randomization (cat /proc/self/map) > > So, is there a way to do such thing easily, or should I write patches by > myself ? realistically the first one is easy if your hw supports the NX bit (x86/x86-64). Some of the other randomisations are present in the 2.6.x kernels. Or run a kernel from Fedora Core, or a kernel with the PaX patches to get all you're asking for. ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: How to enable/disable security features on mmap() ? 2005-12-08 14:14 ` Arjan van de Ven @ 2005-12-08 14:21 ` Emmanuel Fleury 2005-12-08 14:39 ` Emmanuel Fleury 0 siblings, 1 reply; 19+ messages in thread From: Emmanuel Fleury @ 2005-12-08 14:21 UTC (permalink / raw) To: Linux Kernel Hi, Arjan van de Ven wrote: > > realistically the first one is easy if your hw supports the NX bit > (x86/x86-64). Some of the other randomisations are present in the 2.6.x > kernels. > > Or run a kernel from Fedora Core, or a kernel with the PaX patches to > get all you're asking for. In fact, I'm more asking about how to turn it off. These features are already included in the Linux kernel (2.6.14.x at least) but I didn't find any CONFIG_XXX variables to configure these features. (Well, I'm not sure about the NX bit support) Regards -- Emmanuel Fleury The inside of my head was exploding with fireworks. Fortunately, my last thought turned out the lights when it left. -- Calvin & Hobbes (Bill Waterson) ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: How to enable/disable security features on mmap() ? 2005-12-08 14:21 ` Emmanuel Fleury @ 2005-12-08 14:39 ` Emmanuel Fleury 2005-12-08 14:49 ` Arjan van de Ven 0 siblings, 1 reply; 19+ messages in thread From: Emmanuel Fleury @ 2005-12-08 14:39 UTC (permalink / raw) To: Linux Kernel I guess that setting the variable randomize_va_space to 0 just remove the stack pointer (sp) randomization. Seen in arch/i386/kernel/process.c: unsigned long arch_align_stack(unsigned long sp) { if (randomize_va_space) sp -= get_random_int() % 8192; return sp & ~0xf; } Why not having defined this as a CONFIG_STACK_RANDOMIZATION variables (you have some need to avoid to use it in the case of the Crusoe processor: Seen in karch/i386/ernel/cpu/transmeta.c: #ifdef CONFIG_SYSCTL /* randomize_va_space slows us down enormously; it probably triggers retranslation of x86->native bytecode */ randomize_va_space = 0; #endif Regards -- Emmanuel Fleury Elegance is not optional. -- Richard O'Keefe ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: How to enable/disable security features on mmap() ? 2005-12-08 14:39 ` Emmanuel Fleury @ 2005-12-08 14:49 ` Arjan van de Ven 2005-12-08 14:54 ` Emmanuel Fleury 0 siblings, 1 reply; 19+ messages in thread From: Arjan van de Ven @ 2005-12-08 14:49 UTC (permalink / raw) To: Emmanuel Fleury; +Cc: Linux Kernel On Thu, 2005-12-08 at 15:39 +0100, Emmanuel Fleury wrote: > I guess that setting the variable randomize_va_space to 0 just remove > the stack pointer (sp) randomization. > > Seen in arch/i386/kernel/process.c: > > unsigned long arch_align_stack(unsigned long sp) > { > if (randomize_va_space) > sp -= get_random_int() % 8192; > return sp & ~0xf; > } > > Why not having defined this as a CONFIG_STACK_RANDOMIZATION variables well it's a /proc/ variable already! So you can just turn it off entirely at runtime. (what is better is that you use the setarch program to turn it off for selected programs though...) ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: How to enable/disable security features on mmap() ? 2005-12-08 14:49 ` Arjan van de Ven @ 2005-12-08 14:54 ` Emmanuel Fleury 2005-12-08 15:02 ` Emmanuel Fleury 2005-12-08 15:16 ` linux-os (Dick Johnson) 0 siblings, 2 replies; 19+ messages in thread From: Emmanuel Fleury @ 2005-12-08 14:54 UTC (permalink / raw) To: Linux Kernel Arjan van de Ven wrote: > > well it's a /proc/ variable already! So you can just turn it off > entirely at runtime. (what is better is that you use the setarch program > to turn it off for selected programs though...) I knew it was a stupid question ! I fooled myself once more ! ;-) I'll take a look at this familly of variables and at the proc entries. Thanks a lot ! -- Emmanuel Fleury When the gods wish to punish us they answer our prayers. -- Oscar Wilde ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: How to enable/disable security features on mmap() ? 2005-12-08 14:54 ` Emmanuel Fleury @ 2005-12-08 15:02 ` Emmanuel Fleury 2005-12-08 15:16 ` linux-os (Dick Johnson) 1 sibling, 0 replies; 19+ messages in thread From: Emmanuel Fleury @ 2005-12-08 15:02 UTC (permalink / raw) To: Linux Kernel Well, The problem is that is shutdown every randomization at once. But, at least I have some hints were to look now. Thanks again -- Emmanuel Fleury Discontent is the first step in the progress of a man or a nation. -- Oscar Wilde ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: How to enable/disable security features on mmap() ? 2005-12-08 14:54 ` Emmanuel Fleury 2005-12-08 15:02 ` Emmanuel Fleury @ 2005-12-08 15:16 ` linux-os (Dick Johnson) 2005-12-08 15:29 ` Emmanuel Fleury 2005-12-08 15:37 ` Arjan van de Ven 1 sibling, 2 replies; 19+ messages in thread From: linux-os (Dick Johnson) @ 2005-12-08 15:16 UTC (permalink / raw) To: Emmanuel Fleury; +Cc: Linux Kernel On Thu, 8 Dec 2005, Emmanuel Fleury wrote: > Arjan van de Ven wrote: >> >> well it's a /proc/ variable already! So you can just turn it off >> entirely at runtime. (what is better is that you use the setarch program >> to turn it off for selected programs though...) > > I knew it was a stupid question ! I fooled myself once more ! ;-) > I'll take a look at this familly of variables and at the proc entries. > > Thanks a lot ! > -- > Emmanuel Fleury In reference to the random-stack patch.... Executing the following program on linux-2.6.13.4: #include <stdio.h> int main() { int foo; printf("%p\n", &foo); return 0; } ... a few thousand times and sorting its output shows the stack varies from: 0xbf7fe144 -> 0xbffff674 Isn't this too much? I thought the random-stack patch was only supposed to vary it a page or 64k at most. This looks like some broken logic because it varies almost 8 megabytes! No wonder some of my user's database programs sometimes seg-fault and other times work perfectly fine. I think this is incorrect and shows a serious bug (misbehavior). Cheers, Dick Johnson Penguin : Linux version 2.6.13.4 on an i686 machine (5589.55 BogoMips). Warning : 98.36% of all statistics are fiction. . **************************************************************** The information transmitted in this message is confidential and may be privileged. Any review, retransmission, dissemination, or other use of this information by persons or entities other than the intended recipient is prohibited. If you are not the intended recipient, please notify Analogic Corporation immediately - by replying to this message or by sending an email to DeliveryErrors@analogic.com - and destroy all copies of this information, including any attachments, without reading or disclosing them. Thank you. ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: How to enable/disable security features on mmap() ? 2005-12-08 15:16 ` linux-os (Dick Johnson) @ 2005-12-08 15:29 ` Emmanuel Fleury 2005-12-08 15:39 ` Arjan van de Ven 2005-12-08 15:37 ` Arjan van de Ven 1 sibling, 1 reply; 19+ messages in thread From: Emmanuel Fleury @ 2005-12-08 15:29 UTC (permalink / raw) To: Linux Kernel linux-os (Dick Johnson) wrote: > > In reference to the random-stack patch.... > > Executing the following program on linux-2.6.13.4: > > #include <stdio.h> > > int main() > { > int foo; > printf("%p\n", &foo); > return 0; > } > > ... a few thousand times and sorting its output shows > the stack varies from: > 0xbf7fe144 -> 0xbffff674 > > Isn't this too much? I thought the random-stack patch was > only supposed to vary it a page or 64k at most. This looks > like some broken logic because it varies almost 8 megabytes! > No wonder some of my user's database programs sometimes seg-fault > and other times work perfectly fine. I think this is incorrect > and shows a serious bug (misbehavior). Well, there are some other strangeness (especially when running on a x86_64 architecture). See: http://dept-info.labri.fr/~fleury/LS05/download/papers/notes_on_ASLR.txt The ASLR should take advantage of the 64 bits wide address pointers but doesn't. It behaves as on a 32bits architecture. I didn't find why (must be a good reason though but I'm just puzzled). Moreover, the libc location (and all other dynamic libs) is not randomized under x86_64. I have no explanation for this. :-/ Regards -- Emmanuel Fleury I worry about my child and the Internet all the time, even though she's too young to have logged on yet. Here's what I worry about. I worry that 10 or 15 years from now, she will come to me and say 'Daddy, where were you when they took freedom of the press away from the Internet?'. -- Mike Godwin ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: How to enable/disable security features on mmap() ? 2005-12-08 15:29 ` Emmanuel Fleury @ 2005-12-08 15:39 ` Arjan van de Ven 2005-12-08 16:42 ` Nix 0 siblings, 1 reply; 19+ messages in thread From: Arjan van de Ven @ 2005-12-08 15:39 UTC (permalink / raw) To: Emmanuel Fleury; +Cc: Linux Kernel > Well, there are some other strangeness (especially when running on a > x86_64 architecture). See: x86-64 does not have all the randomisation patches yet in mainline, waiting on Andi to approve ;) > Moreover, the libc location (and all other dynamic libs) is not > randomized under x86_64. I have no explanation for this. :-/ see above; in addition prelink may be interfering with this. ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: How to enable/disable security features on mmap() ? 2005-12-08 15:39 ` Arjan van de Ven @ 2005-12-08 16:42 ` Nix 0 siblings, 0 replies; 19+ messages in thread From: Nix @ 2005-12-08 16:42 UTC (permalink / raw) To: Arjan van de Ven; +Cc: Emmanuel Fleury, Linux Kernel On 8 Dec 2005, Arjan van de Ven yowled: >> Moreover, the libc location (and all other dynamic libs) is not >> randomized under x86_64. I have no explanation for this. :-/ > > see above; in addition prelink may be interfering with this. Indeed; prelinked stuff is not randomized. If you want both, prelink with -R gives the same benefits as ASLR of the shared library location, pretty much (obviously the libraries have the same address in every process --- that's kind of the point --- but what that address is is randomly selected at prelink time). Prelinking should not affect stack layout randomization. -- `Don't confuse the shark with the remoras.' --- Rob Landley ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: How to enable/disable security features on mmap() ? 2005-12-08 15:16 ` linux-os (Dick Johnson) 2005-12-08 15:29 ` Emmanuel Fleury @ 2005-12-08 15:37 ` Arjan van de Ven 2005-12-08 16:08 ` linux-os (Dick Johnson) 1 sibling, 1 reply; 19+ messages in thread From: Arjan van de Ven @ 2005-12-08 15:37 UTC (permalink / raw) To: linux-os (Dick Johnson); +Cc: Emmanuel Fleury, Linux Kernel > Isn't this too much? I thought the random-stack patch was > only supposed to vary it a page or 64k at most. This looks > like some broken logic because it varies almost 8 megabytes! that is correct; the 64k was only there for one patch proposal; linus' tree had 8 Mb randomisation from the start > No wonder some of my user's database programs sometimes seg-fault > and other times work perfectly fine. I think this is incorrect > and shows a serious bug (misbehavior). eh how? This 8Mb isn't eaten from the stack rlimit; the entire stack is moved, and the rlimit applies to the size not the position. ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: How to enable/disable security features on mmap() ? 2005-12-08 15:37 ` Arjan van de Ven @ 2005-12-08 16:08 ` linux-os (Dick Johnson) 2005-12-08 16:14 ` Arjan van de Ven 2005-12-08 16:20 ` Xavier Bestel 0 siblings, 2 replies; 19+ messages in thread From: linux-os (Dick Johnson) @ 2005-12-08 16:08 UTC (permalink / raw) To: Arjan van de Ven; +Cc: Emmanuel Fleury, Linux Kernel On Thu, 8 Dec 2005, Arjan van de Ven wrote: > >> Isn't this too much? I thought the random-stack patch was >> only supposed to vary it a page or 64k at most. This looks >> like some broken logic because it varies almost 8 megabytes! > > that is correct; the 64k was only there for one patch proposal; linus' > tree had 8 Mb randomisation from the start > >> No wonder some of my user's database programs sometimes seg-fault >> and other times work perfectly fine. I think this is incorrect >> and shows a serious bug (misbehavior). > > eh how? This 8Mb isn't eaten from the stack rlimit; the entire stack is > moved, and the rlimit applies to the size not the position. The stack moves down! It cannot go below the heap without destroying malloc()ed buffers. I note that the heap also was "dynamically" moved down to accommodate this, but its lower limit can't interfere with _end[], the end of initialized data (fixed by the compiler and data-size in the program). 0xbfbb6d74 Stack 0xb7e97008 Heap 0x80495e8 _end[] An 8 megabyte variation is absolutely insane. It follows the "If a little is good, more must be better..." theory. The purpose of the random stack start, initially proposed by me BTW, was to prevent stack-exploit code from being able to hard-code addresses on the stack. Being off by one byte is enough, 8192 was originally discussed and, I thought, adopted. Eight megabytes is absurd and has no technical basis. Cheers, Dick Johnson Penguin : Linux version 2.6.13.4 on an i686 machine (5589.55 BogoMips). Warning : 98.36% of all statistics are fiction. . **************************************************************** The information transmitted in this message is confidential and may be privileged. Any review, retransmission, dissemination, or other use of this information by persons or entities other than the intended recipient is prohibited. If you are not the intended recipient, please notify Analogic Corporation immediately - by replying to this message or by sending an email to DeliveryErrors@analogic.com - and destroy all copies of this information, including any attachments, without reading or disclosing them. Thank you. ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: How to enable/disable security features on mmap() ? 2005-12-08 16:08 ` linux-os (Dick Johnson) @ 2005-12-08 16:14 ` Arjan van de Ven 2005-12-08 16:24 ` linux-os (Dick Johnson) 2005-12-08 16:20 ` Xavier Bestel 1 sibling, 1 reply; 19+ messages in thread From: Arjan van de Ven @ 2005-12-08 16:14 UTC (permalink / raw) To: linux-os (Dick Johnson); +Cc: Emmanuel Fleury, Linux Kernel > 0xbfbb6d74 Stack > 0xb7e97008 Heap > 0x080495e8 _end[] > there is still a HUGE gap there.... ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: How to enable/disable security features on mmap() ? 2005-12-08 16:14 ` Arjan van de Ven @ 2005-12-08 16:24 ` linux-os (Dick Johnson) 2005-12-08 16:35 ` Arjan van de Ven 0 siblings, 1 reply; 19+ messages in thread From: linux-os (Dick Johnson) @ 2005-12-08 16:24 UTC (permalink / raw) To: Arjan van de Ven; +Cc: Emmanuel Fleury, Linux Kernel On Thu, 8 Dec 2005, Arjan van de Ven wrote: > >> 0xbfbb6d74 Stack >> 0xb7e97008 Heap >> 0x080495e8 _end[] >> > > there is still a HUGE gap there.... > Only because the test program didn't have any global data! You can add the size of any global data to that offset and watch them converge. We have medical imaging programs with great gobs of global data. Cheers, Dick Johnson Penguin : Linux version 2.6.13.4 on an i686 machine (5589.55 BogoMips). Warning : 98.36% of all statistics are fiction. . **************************************************************** The information transmitted in this message is confidential and may be privileged. Any review, retransmission, dissemination, or other use of this information by persons or entities other than the intended recipient is prohibited. If you are not the intended recipient, please notify Analogic Corporation immediately - by replying to this message or by sending an email to DeliveryErrors@analogic.com - and destroy all copies of this information, including any attachments, without reading or disclosing them. Thank you. ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: How to enable/disable security features on mmap() ? 2005-12-08 16:24 ` linux-os (Dick Johnson) @ 2005-12-08 16:35 ` Arjan van de Ven 0 siblings, 0 replies; 19+ messages in thread From: Arjan van de Ven @ 2005-12-08 16:35 UTC (permalink / raw) To: linux-os (Dick Johnson); +Cc: Emmanuel Fleury, Linux Kernel On Thu, 2005-12-08 at 11:24 -0500, linux-os (Dick Johnson) wrote: > On Thu, 8 Dec 2005, Arjan van de Ven wrote: > > > > >> 0xbfbb6d74 Stack > >> 0xb7e97008 Heap > >> 0x080495e8 _end[] > >> > > > > there is still a HUGE gap there.... > > > Only because the test program didn't have any global data! > You can add the size of any global data to that offset and > watch them converge. We have medical imaging programs with > great gobs of global data. 3Gb worth? too bad that code doesn't even run on 2.4 then :) ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: How to enable/disable security features on mmap() ? 2005-12-08 16:08 ` linux-os (Dick Johnson) 2005-12-08 16:14 ` Arjan van de Ven @ 2005-12-08 16:20 ` Xavier Bestel 2005-12-08 16:21 ` Arjan van de Ven 1 sibling, 1 reply; 19+ messages in thread From: Xavier Bestel @ 2005-12-08 16:20 UTC (permalink / raw) To: linux-os (Dick Johnson); +Cc: Arjan van de Ven, Emmanuel Fleury, Linux Kernel On Thu, 2005-12-08 at 17:08, linux-os (Dick Johnson) wrote: > An 8 megabyte variation is absolutely insane. It follows the "If a > little is good, more must be better..." theory. The purpose of > the random stack start, initially proposed by me BTW, was to > prevent stack-exploit code from being able to hard-code addresses > on the stack. Being off by one byte is enough, 8192 was originally > discussed and, I thought, adopted. Eight megabytes is absurd and has > no technical basis. If you only randomize by one or two bytes, the attacker just has to retry once or twice to have his exploit work. Even once in 1024 may be too much for some security-conscious people. The larger the area (with a fixed step), the less statistically efficient the rootkit. Xav ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: How to enable/disable security features on mmap() ? 2005-12-08 16:20 ` Xavier Bestel @ 2005-12-08 16:21 ` Arjan van de Ven 2005-12-08 16:30 ` linux-os (Dick Johnson) 0 siblings, 1 reply; 19+ messages in thread From: Arjan van de Ven @ 2005-12-08 16:21 UTC (permalink / raw) To: Xavier Bestel; +Cc: linux-os (Dick Johnson), Emmanuel Fleury, Linux Kernel On Thu, 2005-12-08 at 17:20 +0100, Xavier Bestel wrote: > If you only randomize by one or two bytes, the attacker just has to > retry once or twice to have his exploit work. in addition the stack pointer needs to be 16 byte aligned in the first place ;) ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: How to enable/disable security features on mmap() ? 2005-12-08 16:21 ` Arjan van de Ven @ 2005-12-08 16:30 ` linux-os (Dick Johnson) 0 siblings, 0 replies; 19+ messages in thread From: linux-os (Dick Johnson) @ 2005-12-08 16:30 UTC (permalink / raw) To: Arjan van de Ven; +Cc: Xavier Bestel, Emmanuel Fleury, Linux Kernel On Thu, 8 Dec 2005, Arjan van de Ven wrote: > On Thu, 2005-12-08 at 17:20 +0100, Xavier Bestel wrote: >> If you only randomize by one or two bytes, the attacker just has to >> retry once or twice to have his exploit work. > > in addition the stack pointer needs to be 16 byte aligned in the first > place ;) > No. The stack-pointer is most efficient on ix86 machines if it is aligned on an ESP-sized boundary (32 bits). Any DATA allocated on the stack __should__ be aligned to take any data-type, i.e., 16 bytes to accommodate floating-point variables. Cheers, Dick Johnson Penguin : Linux version 2.6.13.4 on an i686 machine (5589.55 BogoMips). Warning : 98.36% of all statistics are fiction. . **************************************************************** The information transmitted in this message is confidential and may be privileged. Any review, retransmission, dissemination, or other use of this information by persons or entities other than the intended recipient is prohibited. If you are not the intended recipient, please notify Analogic Corporation immediately - by replying to this message or by sending an email to DeliveryErrors@analogic.com - and destroy all copies of this information, including any attachments, without reading or disclosing them. Thank you. ^ permalink raw reply [flat|nested] 19+ messages in thread
end of thread, other threads:[~2005-12-08 16:43 UTC | newest] Thread overview: 19+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2005-12-08 14:10 How to enable/disable security features on mmap() ? Emmanuel Fleury 2005-12-08 14:14 ` Arjan van de Ven 2005-12-08 14:21 ` Emmanuel Fleury 2005-12-08 14:39 ` Emmanuel Fleury 2005-12-08 14:49 ` Arjan van de Ven 2005-12-08 14:54 ` Emmanuel Fleury 2005-12-08 15:02 ` Emmanuel Fleury 2005-12-08 15:16 ` linux-os (Dick Johnson) 2005-12-08 15:29 ` Emmanuel Fleury 2005-12-08 15:39 ` Arjan van de Ven 2005-12-08 16:42 ` Nix 2005-12-08 15:37 ` Arjan van de Ven 2005-12-08 16:08 ` linux-os (Dick Johnson) 2005-12-08 16:14 ` Arjan van de Ven 2005-12-08 16:24 ` linux-os (Dick Johnson) 2005-12-08 16:35 ` Arjan van de Ven 2005-12-08 16:20 ` Xavier Bestel 2005-12-08 16:21 ` Arjan van de Ven 2005-12-08 16:30 ` linux-os (Dick Johnson)
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox