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/
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.
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)
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
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...)
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
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
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 [email protected] - and destroy all copies of this information, including any attachments, without reading or disclosing them.
Thank you.
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
> 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.
> 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.
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 [email protected] - and destroy all copies of this information, including any attachments, without reading or disclosing them.
Thank you.
> 0xbfbb6d74 Stack
> 0xb7e97008 Heap
> 0x080495e8 _end[]
>
there is still a HUGE gap there....
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
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 ;)
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 [email protected] - and destroy all copies of this information, including any attachments, without reading or disclosing them.
Thank you.
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 [email protected] - and destroy all copies of this information, including any attachments, without reading or disclosing them.
Thank you.
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 :)
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