Any comments on this one?
I'm trying to control the stack and heap randomization via command-line
parameters. I wrote this in a 2.6.15 Ubuntu Dapper kernel and then
patched it into a 2.6.16.16 tree and cleaned it up. It does a few
simple things:
- mmap_random_bits is used to calculate how many pages to shift the
mmap() base around for; I've tested this with 16 bits.
- stack_random_bits is used to calculate how to shift the stack around.
If it's >8, then stack_random_bits - 8 is used to shift the page
alignment of the stack. if it's >0, then its value (or 8 if it's >8) is
used to calculate the interval on which to align the randomly-placed
stack pointer within the first page. If it's 0, no randomization happens.
I boot tested on Dapper and compared paxtest output. Here are the
results on a stock Dapper 2.6.15 kernel on i386:
Anonymous mapping randomisation test : 9 bits (guessed)
Shared library randomisation test : 10 bits (guessed)
Stack randomisation test (SEGMEXEC) : 19 bits (guessed)
Stack randomisation test (PAGEEXEC) : 19 bits (guessed)
This tells me mmap() randomization is about 10 bits, i.e. randomized
over 4 megabytes. This is a bit off... the code says it's really 8
bits, 1024*1024 (1MiB) aligned to a 4096 byte page. It also tells me
the stack is 19 bits, i.e. randomized inside 8MiB, which is correct.
I did a boot with 'mmap_random_bits=16 stack_random_bits=22' with MY
version of the kernel, and got the following results:
Anonymous mapping randomisation test : 17 bits (guessed)
Shared library randomisation test : 17 bits (guessed)
Stack randomisation test (SEGMEXEC) : 22 bits (guessed)
Stack randomisation test (PAGEEXEC) : 22 bits (guessed)
As shown above, the mmap() randomization test (anonmap, shared libs) is
a bit wonky... the stack test is about right. In any case, it looks
like it worked.
Just to make sure, I rebooted and tried the test again on my kernel
without passing parameters, with the following results:
Anonymous mapping randomisation test : 8 bits (guessed)
Shared library randomisation test : 10 bits (guessed)
Stack randomisation test (SEGMEXEC) : 19 bits (guessed)
Stack randomisation test (PAGEEXEC) : 19 bits (guessed)
So it looks to work.
There's a few other things I want to get done, but I'll worry about
those later. They are:
- Take care of the FIXME in that __init code in fs/exec.c to use
architecture-specific #defines for the maximum values of these
parameters, probably in asm-* somewhere.
- Add /proc controls to tweak system-wide randomization on new processes.
- Add LSM/SELinux hooks to let policy tweak randomization per-binary,
so high-order randomization can be used except for with i.e. Oracle
(which tries to mmap() 2GiB in at once and can thus die from VMA
fragmentation).
- Figure out exactly what affects what architecture, and which
architectures react differently in terms of randomization; correct the
calculations in these cases, i.e. if the stack can't be randomized
within the page, stack_random_bits should apply to page randomization.
- Try getting randomization working in other architectures where it's
not right now. I don't see anything obvious to me that shows i.e. Sparc
having randomization.. but I'm not much of a kernel hacker....
- Get somebody to get some sort of heap randomization in here, and do
the same deal. Doesn't Fedora do heap randomization?
In case anyone is wondering, I did this because when this got in I
complained about it not being anywhere near as good as PaX for entropy;
and I got a lot of replies back about how that kind of randomization
fragments VM *and* *breaks* *stuff*. This raises two questions:
- PaX never broke anything I have, so why should I stick with something
weaker?
- On the other hand, if we move to something with that level of entropy
in mainline, some other people who aren't me break. How do we deal with
this?
The solution is simple: I'll use this much entropy, you use that much
entropy, and you can even turn it off if you want to. That's what this
patch does. If you want more or need less, turn the knobs up and down.
--
All content of all messages exchanged herein are left in the
Public Domain, unless otherwise explicitly stated.
Creative brains are a valuable, limited resource. They shouldn't be
wasted on re-inventing the wheel when there are so many fascinating
new problems waiting out there.
-- Eric Steven Raymond
We will enslave their women, eat their children and rape their
cattle!
-- Bosc, Evil alien overlord from the fifth dimension
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Oh, some of my stuff is 4096 hard-coded instead of PAGE_SIZE. I fixed
this in mmap() randomization here, but there's iffiness coming up for
the stack.
The stack is page aligned and randomized in the VMA; then randomized to
16 byte intervals. This is fine, PAGE_SIZE is 4096, our intervals are
16, 256 positions, we randomize 2^(stack_random_bits - 8) VMA and 2^8
inside; unless we have less than 8 bits, then we randomize
2^stack_random_bits and align to PAGE_SIZE / (2^stack_random_bits).
Easy enough. Now what if PAGE_SIZE isn't 4096?
That's an easy problem too. This can easily be calculated straight
forward with the number ... 8. In fact that's how I did it. 2^8 is
4096 / 16. Thus, the solution is log_base_2(PAGE_SIZE/16) instead of 8!
Now. How do I find the base 2 log of a number in the kernel?
John Richard Moser wrote:
> Any comments on this one?
>
> I'm trying to control the stack and heap randomization via command-line
> parameters. I wrote this in a 2.6.15 Ubuntu Dapper kernel and then
> patched it into a 2.6.16.16 tree and cleaned it up. It does a few
> simple things:
>
[SNIP]
- --
All content of all messages exchanged herein are left in the
Public Domain, unless otherwise explicitly stated.
Creative brains are a valuable, limited resource. They shouldn't be
wasted on re-inventing the wheel when there are so many fascinating
new problems waiting out there.
-- Eric Steven Raymond
We will enslave their women, eat their children and rape their
cattle!
-- Bosc, Evil alien overlord from the fifth dimension
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2.2 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iQIVAwUBRG6OsAs1xW0HCTEFAQLV4A/7BduRbAsWgvCy8ZMMRVYze33nkjGaK+o7
jd7EN7r+pcwr5EDKG4NdryTj+MdoSQJuAjy8eclaRFxJtu9jugE6e/q/wNlxRe9y
7q2mx4imNcrhVJ0TXKi6HL139lqON2kp4T4MlARLmwqy0zmtSjRGYUOAkxsYoXbp
5XvYe550O12caqGJvpWjPsv7hDMBSVmuo0i98SHCY9piafZtLl0rqgiVfRKicukq
ErmQd8UEhwjCwwqA34+6g9cR8107T6qvWucBqK4z9MDl65VrlnBQvzgdWb+Y6hDw
wUdX54E+si/1dsvUu9+cA9zZuHUeNOEaTPZB0Kirtdmkv5XRiorZ8PMjCLgFrhEW
05Vn2CmrJL7a+1bkOYBYal1eZbg2xgEKIeqE4SeMkkRdnmmr7BJwGh5h9LcMAVra
QCiMf7T4yV6qPLlYiuad/SUshel0YauTC63EcG4qO37Gx93amKgGyzCef2bVWc4T
iPOSG3YVIorrZIy1ZWOSQSfcmSappLx52vagbHYQOHKHtlBazz0elI730LDRQxCr
H4CfByfmf4GsoCWg7+aZ5awruh0Q8qXjLXRRunhhCBiz5Y3h+6uzh786Vuv13+Be
TuvVJ/ZYQrVKbpGvRXHYN6GC4Wx2Tl5HiMDLCvU0lVYMv+uH3c0b2eOfi7VpE5SZ
rimyC8GoqyA=
=jOSA
-----END PGP SIGNATURE-----
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
John Richard Moser wrote:
[...]
>
> There's a few other things I want to get done, but I'll worry about
> those later. They are:
>
> - Take care of the FIXME in that __init code in fs/exec.c to use
> architecture-specific #defines for the maximum values of these
> parameters, probably in asm-* somewhere.
[...]
Working on this right now. I've fixed the 4096 hard-coded page sizes
and made them work with PAGE_SIZE; the stack was fun, I had to use a
long_log2() and calculate how many page_random_bits were possible and
cut that out to see if any vma_random_bits were left and how many. :)
I'm also looking at using STACK_RANDOM_BITS_MAX_X86 or something because
of IA-32 emulation on x86-64. I definitely need to figure out how to
make that work cleanly; on x86-64 we may have more stack/heap entropy
than sane, and I'd rather limit that (at first; later comes--
confusion-- stack_random_bits32= mmap_random_bits32=).
While I'm at it, does anyone see anything else glaring I should fix? (I
am actually trying to get this merged, yes...)
- --
All content of all messages exchanged herein are left in the
Public Domain, unless otherwise explicitly stated.
Creative brains are a valuable, limited resource. They shouldn't be
wasted on re-inventing the wheel when there are so many fascinating
new problems waiting out there.
-- Eric Steven Raymond
We will enslave their women, eat their children and rape their
cattle!
-- Bosc, Evil alien overlord from the fifth dimension
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2.2 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iQIVAwUBRG6n4As1xW0HCTEFAQJryRAAgGr+XuOwG2hIVx+1RNmqcyVUC0sYew3D
9OFkV4PcyIUwGBmJcUWXzkV46av3Fz3Gk5Dm7X7KMpbroUz0big4MiZTeLRPsoCN
s99pDqciPe+YGjqj3KcIdwFT+ryUSpIAI4K8pMu2unqejf53T0QQR/7w7bkUqoOe
tj/L5GwubpJH2SNvWuBwHHNtOisuSBkXYIj90swfijbmiccAWki7i50I7Svd14db
uYWS8RvxMTUYEKbhW363OdlkVp0cvrbaIh2UYcEH4P2g7tcdzgG/aP9dUzQPDk0W
r5ltVMlGbVp1K1IPXuEn8S8gSmufPCq8AahQlVhiMiIqk4K1cw87tzY6H4UjE0dH
AyQ+NLQKy8RsOYDnfb4eM/x3JDJjF8RHHxPqVuRTRtA+tA+N2GKFwbOMsVvGj+PV
GYzaH/XAKzvccWWBlhFu2YQG9ZQqy+dpfCotvrbYQPfiuYj7+1yRdE7BaFUAMO6P
MVXf+tY1wzIZ9vEjIhYZtbq4VHNzwp43Jm0sHLdkUm9BPJzLoZbExC86BY5L6U2X
QG0SV3EyzT7wUga+28jbcG77aFEVR6ZhNLa3MFVqO6hF7ApTiJRooU5k4m7XUzx7
qlhhFFcB4HFTFV6o9Usp7YkGQnwmVKmtFOz/nY0COuJiQCRU4jby30NgPhCH+li2
VJz/1v+bBCs=
=yTDy
-----END PGP SIGNATURE-----
On Fri, 2006-05-19 at 21:00 -0400, John Richard Moser wrote:
> Any comments on this one?
>
> I'm trying to control the stack and heap randomization via command-line
> parameters.
why? this doesn't really sound like something that needs to be tunable
to that extend; either it's on or it's off (which is tunable already),
the exact amount should just be the right value. While I often disagree
with the gnome desktop guys, they have some point when they say that
if you can get it right you shouldn't provide a knob.
(if we would put a knob on everything that is a value in the kernel we'd
have five gazilion knobs)
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Arjan van de Ven wrote:
> On Fri, 2006-05-19 at 21:00 -0400, John Richard Moser wrote:
>> Any comments on this one?
>>
>> I'm trying to control the stack and heap randomization via command-line
>> parameters.
>
> why? this doesn't really sound like something that needs to be tunable
> to that extend; either it's on or it's off (which is tunable already),
> the exact amount should just be the right value. While I often disagree
> with the gnome desktop guys, they have some point when they say that
> if you can get it right you shouldn't provide a knob.
This is a "One Size Fits All" argument.
Oracle breaks with 256M stack/mmap() randomization, so does Linus' mail
client. That's why we have 8M stack and 1M mmap().
On the other hand, some things[1][2][3] may give us the undesirable
situation where-- even on an x86-64 with real NX-bit love-- there's an
executable stack. The stack randomization in this case can likely be
weakened by, say, 8 bits by padding your shellcode with 1-byte NOPs
(there's a zillion of these, like inc %eax) up to 4096 bytes. This
leaves 1 success case for every 2047 fail cases.
Picture (for example) a Gaim bug, assuming Gaim has this sort of stack
issue[1]. Let us also assume that an attacker has an efficient way to
locate random, valid MSNIM, AIM, YIM, and ICQ users who are on-line (not
unreasonable, esp. since you can search YIM). Let us also assume that
Linux happens to be the major desktop platform, and thus this kind of
security is worth our time in the first place.
Let an attacker distribute a worm via sending instant messages that
trigger this bug, with an initial attack spread of 10,000; that is, the
initial attacker attacks 10,000 users. Given 1 attack per second, an
iteration is 2 hours 46 minutes. Approximately 5 should be infected.
These 5 should now each attack 10,000 other users. This means most
likely 50,000 un-infected are attacked (assuming overlap is negligible),
likely penetration is now 200.
Third iteration, 200 * 10,000 == 2,000,000 attacks. Likely success
would be 1,000.
Third iteration is 10,000,000 attacks and 5,000 newly infected.
Fourth iteration is 500,000,000 and 250,000.
Fifth iteration is 2,500,000,000 and 1,250,000.
At this point we are 13 hours 50 minutes in, with 1.25 million hosts
infected. IDS/IPS vendors should be releasing signatures by now;
anti-virus vendors should have new signatures out already. Most people
will not get them for a few days, maybe a week; random distribution of
Linux perhaps has clam with freshclam running daily, but it's not
auto-scanning.
Around this time, someone should also have figured out what the worm is
attacking. A patch will be issued by the next iteration; it doesn't
exist yet because this is a zero-day attack, exactly what randomization
is made to stop. The patch will take 1-2 more days (5-15 more
iterations just about) to be built, tested, and distributed across all
major distributions; no guarantees that anyone will install it at first.
If we assume stack randomization across 256MiB, that's 65536 places that
the attacker has to overcome. The first iteration probably doesn't get
anywhere; the attacker will likely have to attack 65536 times (18h12m @
1/S) to start, and then each iteration is that many attacks with 1
infection per attacker. The fifth iteration is 90 hours (3 days 18
hours) away, and on average 16 nodes should be infected by this time.
It takes roughly 76 days to reach where 1.25 million infections in
theory. This is on order of 130 times longer. This is nice, because it
gives end users and developers more time to react, figure out what's
going on, correct the flaws, write patches, build patches, test patches,
and apply patches. MORE TIME.
If we have a 64-bit address space we could easily place this where it
takes billions of attacks (literally, randomize over a 16TiB area; VMA
is 256TiB and the kernel cuts it down to what 80TiB?) before one is
likely to actually infect something, around 136 years per iteration. At
this point we have left the realm of "giving the user more time to
react" and reached a situation where we can say this SHOULD never
actually happen. "Should" because once every 136.0993 years, when the
moon reflects off the ionosphere just right to create a twin-moons
illusion, the stars twinkle in the right way, and the wind is blowing in
just the right direction, one person in the world falls to a successful
attack.
The reason I wrote (and am still working on) this patch is because I
neither want nor need you to agree with me on how much is enough. What
won't hurt me will help me; but it might break Joe Enterprise's Oracle
server, or Linus' mail client. Still, Joe Enterprise by default will
get a set-up that's insufficient for my needs, but won't break his
enterprise-critical apps unless he specifically asks it to.
In the future the command line parameter can die, in favor of SELinux
policy hooks. SELinux will eventually be integrated with even basic
desktop distributions; it's no big deal to have the default policy
specify stack_random_bits and mmap_random_bits, as long as that policy
gets loaded before init (i.e. patch init so it loads the policy
immediately and reloads self; or use an initrd that loads the policy and
replaces itself with init). At that time this can all just become
infrastructure for those policy controls, because this stuff is policy
if anything.
[1] https://launchpad.net/distros/ubuntu/+source/gaim/+bug/34129 (2.0
and 1.5 both!)
[2] https://launchpad.net/distros/ubuntu/+source/firefox/+bug/34131
[3]
https://launchpad.net/distros/ubuntu/+source/mozilla-thunderbird/+bug/34132
> (if we would put a knob on everything that is a value in the kernel we'd
> have five gazilion knobs)
>
>
>
- --
All content of all messages exchanged herein are left in the
Public Domain, unless otherwise explicitly stated.
Creative brains are a valuable, limited resource. They shouldn't be
wasted on re-inventing the wheel when there are so many fascinating
new problems waiting out there.
-- Eric Steven Raymond
We will enslave their women, eat their children and rape their
cattle!
-- Bosc, Evil alien overlord from the fifth dimension
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2.2 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iQIVAwUBRG80gQs1xW0HCTEFAQJWBw//ZEKuhF/lKpKfZvwfwRTc7cQ48NspJnoC
xTIk9o0EVwXdqRBVSXlPU8Dwe+d4OdtwhYy3LxWasE/ZdTbJJC59TSjNWKrf0noM
c0J9e4CTFZXRVZyHBr9LJCZZgkZA03GVOvqU1hmo/YmNrrh5y4Txq3JrZEunpbOS
r3fBSdx/2ARCU/oEYkKx+D67Ilng2+OaYjdBj9HcCpX77eyYExsn5h+kD8S+C9xP
u1Yz+sAyTqJFEB/rmzsjA3pdltluEFB3BRrbHVeWkx7cV3TohFPWuaoCWfW3Yr0n
QzdRjxfmaarFPNV/gbV4WhDdNX57huD7ggf4v3sCPV1tLeNFhxrfrTwO2Vm/7kC0
xg6ves7+7DbqsZx3KLwFGHeGnvtVlXoFd4J0a9T2vN72FQm1O3zwEJxOfx14DBlo
KbXpA9oxEMPuedSMEd3i6WcH9onuiVCBz3RcwpUPt9gMppKZf9DQIErmrmz7Rd/3
YJdyn3Kp1zr3TAumgAHCHHuLKXiJHVfvAUYpgemjBXWHWDRg7RI57b8TD3G1659i
l8db3ymNKeta4RwENSpj3R2Z1miLNA7tNoSW3FyfFJNvmfokv0h7fXTV0xn4JjHu
yeG6Vu+KWrGrt6oRtdPCaoGMOSpmuIvZMSfNkuwDHPANxVdc2LifXIU+I6t6s2qz
N8yCk9YulVA=
=CyQx
-----END PGP SIGNATURE-----
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
John Richard Moser wrote:
[...]
I've got a new working version over here, it's currently building over
on my laptop for test. It looks a lot cleaner now, still a little messy
in some places for my tastes... a few functions I declare 2-5 more
variables in!
I also haven't fixed the arch_align_stack() in
arch/um/kernel/process_kern.c to match... and I'm getting tired of
maintaining 3 copies of what started as the same exact code and is
currently STILL the same exact code, just 15 times bigger! Does anyone
have a good place to stick arch_align_stack()? It can stay wrapped in
#ifndef like in arch/um/kernel/process_kern.c, because this method
should work for all architectures that don't '#define
arch_align_stack(x) (x)'.
> - stack_random_bits is used to calculate how to shift the stack around.
> If it's >8, then stack_random_bits - 8 is used to shift the page
> alignment of the stack. if it's >0, then its value (or 8 if it's >8) is
> used to calculate the interval on which to align the randomly-placed
> stack pointer within the first page. If it's 0, no randomization happens.
>
At this point, it actually calculates how many bits go into sub-page
randomization with long_log2(PAGE_SIZE / 16) instead of just assuming 8.
[...]
>
>
> There's a few other things I want to get done, but I'll worry about
> those later. They are:
>
> - Take care of the FIXME in that __init code in fs/exec.c to use
> architecture-specific #defines for the maximum values of these
> parameters, probably in asm-* somewhere.
Fixed. We no longer care. In arch/i386/mm/mmap.c; fs/binfmt_elf.c;
arch/i386/kernel/process.c; and arch/x86-64/kernel/process.c, we
calculate the maximum amount of entropy based on how many bits can be
done in (TASK_SIZE / 6). This as an intended side effect also means
that IA-32 emulation on x86-64 results in proper reduction of entropy
(down to 256MiB ranges for stack and mmap())
> - Add /proc controls to tweak system-wide randomization on new processes.
Arjan van de Ven raised a good point:
"(if we would put a knob on everything that is a value in the kernel
we'd have five gazilion knobs)"
We don't need /proc control for this; SELinux control should be enough.
The kernel command line parameter could be removed as soon as SELinux
policy could adjust these settings; the default values when no
parameters are given are the settings the kernel uses now.
> - Add LSM/SELinux hooks to let policy tweak randomization per-binary,
> so high-order randomization can be used except for with i.e. Oracle
> (which tries to mmap() 2GiB in at once and can thus die from VMA
> fragmentation).
Don't have these yet; although I put a couple /*XXX: */ comments in
where I feel these should go.
> - Figure out exactly what affects what architecture, and which
> architectures react differently in terms of randomization; correct the
> calculations in these cases, i.e. if the stack can't be randomized
> within the page, stack_random_bits should apply to page randomization.
> - Try getting randomization working in other architectures where it's
> not right now. I don't see anything obvious to me that shows i.e. Sparc
> having randomization.. but I'm not much of a kernel hacker....
Really, really would be nice.... a little help here? :)
> - Get somebody to get some sort of heap randomization in here, and do
> the same deal. Doesn't Fedora do heap randomization?
Anyone have an answer for this one? I can't get Fedora Core 5 working
in Qemu (install DVD hangs as soon as it sees the hard drive) and I
can't find an FC5 LiveCD...
[...]
- --
All content of all messages exchanged herein are left in the
Public Domain, unless otherwise explicitly stated.
Creative brains are a valuable, limited resource. They shouldn't be
wasted on re-inventing the wheel when there are so many fascinating
new problems waiting out there.
-- Eric Steven Raymond
We will enslave their women, eat their children and rape their
cattle!
-- Bosc, Evil alien overlord from the fifth dimension
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2.2 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iQIVAwUBRG9ORQs1xW0HCTEFAQIvlA/+P8bLXdW2yqYewVgDJzYjsSsy/c0Fgzy+
2SY5sJjMMbS08+gfSqSbIRtAZf2N7iJLOxWP1JpwWoZxVj+QMSDWEEmt4552/bi1
00yMwQ6aFmF3nkCXwpj2mLiR8P8KFQJp4U0LPaOOlEt8/6OJgC+wbR2B0nm4rxFg
RRgaNeeenB95smfis54cu64EFyTwxlsNdW7H47Zgu7SBnNsmSAf2iZ3b5Gf4zTaA
PhH8syEMxH2SGwwkEumylDdmIUBw/5yzSIwmevp7wrG8SNHuaCE9LI1lR6bSubNu
84Wmiq4hv+kIYdm+9hdnOcC/27THKHCFq9JawMDnvcZMYQmvJDMiO++aHfRufhl7
wm0bAMfgObDVy+WJOyCfryGxb6DZv9xvktXfTj7xEtsRm8DWbGdbiivoOm6Kk7tc
PuEJJqOy2gHGPfM18RVYAfdspkYcc55VAJhwIMEux+ATLOf4Y30kaWi3VLP8pXLo
6m0pJFeaLKS+fAwXnc3PYWbzpCmrZAr8ZFamhfLlEnA/8i8siNQCw98WhEXIxUkI
wtUFnHFPhtC2QkDn/fNnbYpSMR+SQOOOBK7+u8U2WrCZEuaFif1Pq7XULGWSfHPq
RW3s/jzEjLc+ngvGEqrADIglde/ced4CrEhRHH4RQQrjn5DhseXh8euQ+3qG69wU
EQU3Fw0XQ/Y=
=yYp4
-----END PGP SIGNATURE-----
On So 20-05-06 11:23:47, John Richard Moser wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
>
>
> Arjan van de Ven wrote:
> > On Fri, 2006-05-19 at 21:00 -0400, John Richard Moser wrote:
> >> Any comments on this one?
> >>
> >> I'm trying to control the stack and heap randomization via command-line
> >> parameters.
> >
> > why? this doesn't really sound like something that needs to be tunable
> > to that extend; either it's on or it's off (which is tunable already),
> > the exact amount should just be the right value. While I often disagree
> > with the gnome desktop guys, they have some point when they say that
> > if you can get it right you shouldn't provide a knob.
>
> This is a "One Size Fits All" argument.
>
> Oracle breaks with 256M stack/mmap() randomization, so does Linus' mail
> client. That's why we have 8M stack and 1M mmap().
>
> On the other hand, some things[1][2][3] may give us the undesirable
> situation where-- even on an x86-64 with real NX-bit love-- there's an
> executable stack. The stack randomization in this case can likely be
> weakened by, say, 8 bits by padding your shellcode with 1-byte NOPs
> (there's a zillion of these, like inc %eax) up to 4096 bytes. This
> leaves 1 success case for every 2047 fail cases.
Maybe we can add more bits of randomness when there's enough address
space -- like in x86-64 case?
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Pavel Machek wrote:
> On So 20-05-06 11:23:47, John Richard Moser wrote:
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA1
>>
>>
>>
>> Arjan van de Ven wrote:
>>> On Fri, 2006-05-19 at 21:00 -0400, John Richard Moser wrote:
>>>> Any comments on this one?
>>>>
>>>> I'm trying to control the stack and heap randomization via command-line
>>>> parameters.
>>> why? this doesn't really sound like something that needs to be tunable
>>> to that extend; either it's on or it's off (which is tunable already),
>>> the exact amount should just be the right value. While I often disagree
>>> with the gnome desktop guys, they have some point when they say that
>>> if you can get it right you shouldn't provide a knob.
>> This is a "One Size Fits All" argument.
>>
>> Oracle breaks with 256M stack/mmap() randomization, so does Linus' mail
>> client. That's why we have 8M stack and 1M mmap().
>>
>> On the other hand, some things[1][2][3] may give us the undesirable
>> situation where-- even on an x86-64 with real NX-bit love-- there's an
>> executable stack. The stack randomization in this case can likely be
>> weakened by, say, 8 bits by padding your shellcode with 1-byte NOPs
>> (there's a zillion of these, like inc %eax) up to 4096 bytes. This
>> leaves 1 success case for every 2047 fail cases.
>
> Maybe we can add more bits of randomness when there's enough address
> space -- like in x86-64 case?
> Pavel
Yes but how many? I set the max in my working copy (by the way, I
patched it into Ubuntu Dapper kernel, built, tested, it works) at 1/12
of TASK_SIZE; on x86-64, that's 128TiB / 12 -> 10.667TiB -> long_log2()
- -> 43 bits -> 8TiB of VMA, which becomes 31 bits mmap() and 39 bits stack.
That's feasible, it's nice, it's fregging huge. Can we justify it? ...
well we can't justify NOT doing it without the ad hominem "We Don't Need
That Because It's Not Necessary", but that's not the hard part around here.
I say that's the max, and let the kernel devs figure out where they
think it "should" be and the sysadmin define where he thinks it "needs
to" be, with policy. For now I can toy with the hooks with the command
line-- I originally wanted that and /proc, but discarded that when Arjan
started talking about too many knobs.
For now I'm not going to simply roll out an
infrastructure-and-SELinux-hooks patch; one step at a time, plus I don't
know HTF to add an SELinux hook and policy control for it. Maybe if I
can get a cleaned-up patch into -mm someone will pick it up and write an
SELinux hook for it.
On a side note, paxtest says FC5 has 19 bits of stack randomization
(Mainline does too-- 8MiB), and it can't seem to decide if it's 8 or 12
bits of mmap() (mainline has 8, paxtest detects 9 or 10....). I was
sure they had more...
What they DO have that I'm waiting to see in mainline is a random heap
base. 'cat /proc/self/maps' changes things around for everything but
/bin/cat, that is nice. This appears to shift around in 16MiB... (12 bits!)
- --
All content of all messages exchanged herein are left in the
Public Domain, unless otherwise explicitly stated.
Creative brains are a valuable, limited resource. They shouldn't be
wasted on re-inventing the wheel when there are so many fascinating
new problems waiting out there.
-- Eric Steven Raymond
We will enslave their women, eat their children and rape their
cattle!
-- Bosc, Evil alien overlord from the fifth dimension
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2.2 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iQIVAwUBRHEmBAs1xW0HCTEFAQLJaQ/7B8iKaI4PXp/cl/9jS2ssCkw8UdZdN0kF
xxTbLbKvBJwqeo64G0+3j6ZacRLgzRLaGGum5tLyaBWE02fAvNVGH/naAHbfY7Ks
yDPA8bgazlHKym5x/yNPZog2f5tOP0e3Hf3XLQx1yLqLR6Qjs8lLN8APVZVzq+pG
z3FFvdHlm9HLyM2qDw1nm+DtSPkTOU6ddbyYuWcYW1RUI02JlTf3uNeS00dHekK7
vGMBwVinbKOViCWFhGNACxB+sYShQ5L+m9vdb4lWht1npljcFKCIHarEcQZ1yIEp
RyvB5hMjF6YGBoyUgyTklw+FFtrY3xFdB1yt1e+oKABo1vJK+wmO7xujVa0VX4eP
ZW33OE0zo+NnTCXCIt8s7w9S8E2P6Vnn+IEaqseRl+Crhi0AZ/b9OXHBysdO2Ax/
YzUN0VKnaiWBSX92OPIp8oaKdtpf9VKoW5FG9dIGMb79ruykTtGA3s1Py2xswslZ
2dr9yflS8X7Mckws6iD3Uyx6RSUatjCXUHF/NMr9bOMVE0r8jvP/A0K/2TloKcGa
c7gMBjAI30J++/suyjdpg5zLGQSA9yWG/xnobjGCLi7IYTTNxtu8HASRiXnQfYJy
sOZcFbhN/CNJpVTHwHRykvM14wd38bIOis/qSGIJFjhJe5lm3v+cSh9u66Ta9AK+
wuJoJqntf3w=
=0o7I
-----END PGP SIGNATURE-----
Hi!
> >>> On Fri, 2006-05-19 at 21:00 -0400, John Richard Moser wrote:
> >>>> Any comments on this one?
> >>>>
> >>>> I'm trying to control the stack and heap randomization via command-line
> >>>> parameters.
> >>> why? this doesn't really sound like something that needs to be tunable
> >>> to that extend; either it's on or it's off (which is tunable already),
> >>> the exact amount should just be the right value. While I often disagree
> >>> with the gnome desktop guys, they have some point when they say that
> >>> if you can get it right you shouldn't provide a knob.
> >> This is a "One Size Fits All" argument.
> >>
> >> Oracle breaks with 256M stack/mmap() randomization, so does Linus' mail
> >> client. That's why we have 8M stack and 1M mmap().
> >>
> >> On the other hand, some things[1][2][3] may give us the undesirable
> >> situation where-- even on an x86-64 with real NX-bit love-- there's an
> >> executable stack. The stack randomization in this case can likely be
> >> weakened by, say, 8 bits by padding your shellcode with 1-byte NOPs
> >> (there's a zillion of these, like inc %eax) up to 4096 bytes. This
> >> leaves 1 success case for every 2047 fail cases.
> >
> > Maybe we can add more bits of randomness when there's enough address
> > space -- like in x86-64 case?
>
> Yes but how many? I set the max in my working copy (by the way, I
> patched it into Ubuntu Dapper kernel, built, tested, it works) at 1/12
> of TASK_SIZE; on x86-64, that's 128TiB / 12 -> 10.667TiB -> long_log2()
> - -> 43 bits -> 8TiB of VMA, which becomes 31 bits mmap() and 39 bits stack.
>
> That's feasible, it's nice, it's fregging huge. Can we justify it? ...
> well we can't justify NOT doing it without the ad hominem "We Don't Need
> That Because It's Not Necessary", but that's not the hard part around here.
Well, making it configurable and pushing hard decision to the user is
not right approach, either. I believe we need different
per-architecture defaults, not "make user configure it".
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Pavel Machek wrote:
> Hi!
>
>>>>> On Fri, 2006-05-19 at 21:00 -0400, John Richard Moser wrote:
>>>>>> Any comments on this one?
>>>>>>
>>>>>> I'm trying to control the stack and heap randomization via command-line
>>>>>> parameters.
>>>>> why? this doesn't really sound like something that needs to be tunable
>>>>> to that extend; either it's on or it's off (which is tunable already),
>>>>> the exact amount should just be the right value. While I often disagree
>>>>> with the gnome desktop guys, they have some point when they say that
>>>>> if you can get it right you shouldn't provide a knob.
>>>> This is a "One Size Fits All" argument.
>>>>
>>>> Oracle breaks with 256M stack/mmap() randomization, so does Linus' mail
>>>> client. That's why we have 8M stack and 1M mmap().
>>>>
>>>> On the other hand, some things[1][2][3] may give us the undesirable
>>>> situation where-- even on an x86-64 with real NX-bit love-- there's an
>>>> executable stack. The stack randomization in this case can likely be
>>>> weakened by, say, 8 bits by padding your shellcode with 1-byte NOPs
>>>> (there's a zillion of these, like inc %eax) up to 4096 bytes. This
>>>> leaves 1 success case for every 2047 fail cases.
>>> Maybe we can add more bits of randomness when there's enough address
>>> space -- like in x86-64 case?
>> Yes but how many? I set the max in my working copy (by the way, I
>> patched it into Ubuntu Dapper kernel, built, tested, it works) at 1/12
>> of TASK_SIZE; on x86-64, that's 128TiB / 12 -> 10.667TiB -> long_log2()
>> - -> 43 bits -> 8TiB of VMA, which becomes 31 bits mmap() and 39 bits stack.
>>
>> That's feasible, it's nice, it's fregging huge. Can we justify it? ...
>> well we can't justify NOT doing it without the ad hominem "We Don't Need
>> That Because It's Not Necessary", but that's not the hard part around here.
>
> Well, making it configurable and pushing hard decision to the user is
> not right approach, either. I believe we need different
> per-architecture defaults, not "make user configure it".
Yes, different per-architecture defaults is feasible with configuration
being possible. I could replace 'int STACK_random_bits=19' with 'int
mmap_random_bits=ARCH_STACK_RANDOM_BITS_DEFAULT' and that would be
effective as long as the user doesn't touch it with command line or
SELinux or whatnot.
It is still possible that ARCH_STACK_RANDOM_BITS_DEFAULT breaks things.
The current kernel default broke emacs at first I heard; I believe we
started with 64KiB of stack randomization and then upped it to 8MiB when
emacs was fixed. In this case we have 3 options:
- Disable PF_RANDOMIZE for the binary. (Already doable)
- Decrease randomization system-wide. (My patch lets you do this)
- Decrease randomization for the binary to a point where it works.
(Adding SELinux hooks and policy to my patch would allow this)
Obviously decreasing randomization system-wide has other implications:
your entire system is as weak as the weakest link, even if that weakest
link is a privilege-restricted non-networked text editor. Another
consideration is that Oracle breaks with high-order entropy; but Apache
is quickly brute-forceable even with high-order entropy (216 seconds an
average according to a paper about brute forcing PaX ASLR on i386). We
increase the risk here to fit the need there... not good.
Disabling randomization for the binary is much more fine-grained, but
opens up that binary for attacks. Oracle breaks with high-order
entropy; we can disable randomization on Oracle and keep high-order
entropy, but now the database server is at risk. This isn't the
greatest idea in the world either.
Decreasing randomization as per policy on specific binaries is a
security win. Apache is much safer with high-entropy ASLR; Oracle
breaks from it but lives with low-entropy ASLR and that's better than
nothing; most of the rest of the system doesn't really care and some
benefits some doesn't. The only problem is somebody has to configure
that, putting load on the administrator.
It appears to me that the best solution is per-policy, but we should
leave even that up to the user. This means make a sane default-- one
that shouldn't break anything, but supplies some kind of benefit-- and
only stray from that at the user's request. This is why I wrote a
command line patch and am interested in SELinux policy controls for
randomization entropy.
> Pavel
- --
All content of all messages exchanged herein are left in the
Public Domain, unless otherwise explicitly stated.
Creative brains are a valuable, limited resource. They shouldn't be
wasted on re-inventing the wheel when there are so many fascinating
new problems waiting out there.
-- Eric Steven Raymond
We will enslave their women, eat their children and rape their
cattle!
-- Bosc, Evil alien overlord from the fifth dimension
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2.2 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iQIVAwUBRHHnfgs1xW0HCTEFAQJ/Tw//fYWCveTJdDvtAce8/Yesa/thMLRmoDZ8
s2DBL66gNb+Aw35d9Fir9H/K2OzCZhDgAyJcQoMS2qckRyDTYDAX4ygBipQqeTng
SpoECxrPogGNqzZ/H55/8ngv1pGaiRS9Ui82xv2z5J2AGHt413jp50wskDbmiuC0
yrosPds8ULiyDXumouictYE4/EY3L77b9b45xNAY5m2nhnnzjv9Z96J4MZuLSUP1
8lKMgEx0AWLv2N7ZtAVVbq5KnariHS2NgN5Y2R+7fcobrN+WezoDQGoqerYY9Fq5
WO/R+C1+LBb43bHAIW3EvKz39rIaBnQZN53RQACzNVepfg6txfKDPEvUDIJvTGne
tjgmvPLq5L0NRqHVG1ZjI5wDmj4GvIrpTVoEjFlUT4pfJzreI3Ene8bWrK6zrnPa
AFcw4LMpB1+Biki5GD3rXg4MTPY2v8RpwqvR3Pg+F/m/DQmvIP4NAIp3kFQAJfXr
daCRdr0K/iB8ZJb8l2i5sVUqbV7FZOLSMn4+0vJOGbfkCRy3yMCnMF7KdTkHCBAf
y96z6G+4AWAdVrmmJwYEEJYGTt10TNbISkxk8l40H1V044oX2AtiifX3zTWVO0IE
xAIoxH8eyopVB8KJk2msjBqLvpcryNAVsGA/ZvcxosKwcljyoLKIG0FsLE++XbvX
Qzyw3S+i40k=
=lEaM
-----END PGP SIGNATURE-----
Hi!
> >>>> On the other hand, some things[1][2][3] may give us the undesirable
> >>>> situation where-- even on an x86-64 with real NX-bit love-- there's an
> >>>> executable stack. The stack randomization in this case can likely be
> >>>> weakened by, say, 8 bits by padding your shellcode with 1-byte NOPs
> >>>> (there's a zillion of these, like inc %eax) up to 4096 bytes. This
> >>>> leaves 1 success case for every 2047 fail cases.
> >>> Maybe we can add more bits of randomness when there's enough address
> >>> space -- like in x86-64 case?
> >> Yes but how many? I set the max in my working copy (by the way, I
> >> patched it into Ubuntu Dapper kernel, built, tested, it works) at 1/12
> >> of TASK_SIZE; on x86-64, that's 128TiB / 12 -> 10.667TiB -> long_log2()
> >> - -> 43 bits -> 8TiB of VMA, which becomes 31 bits mmap() and 39 bits stack.
> >>
> >> That's feasible, it's nice, it's fregging huge. Can we justify it? ...
> >> well we can't justify NOT doing it without the ad hominem "We Don't Need
> >> That Because It's Not Necessary", but that's not the hard part around here.
> >
> > Well, making it configurable and pushing hard decision to the user is
> > not right approach, either. I believe we need different
> > per-architecture defaults, not "make user configure it".
>
> Yes, different per-architecture defaults is feasible with configuration
> being possible. I could replace 'int STACK_random_bits=19' with 'int
> mmap_random_bits=ARCH_STACK_RANDOM_BITS_DEFAULT' and that would be
> effective as long as the user doesn't touch it with command line or
> SELinux or whatnot.
>
> It is still possible that ARCH_STACK_RANDOM_BITS_DEFAULT breaks things.
> The current kernel default broke emacs at first I heard; I believe
> we
Well, fix emacs then. We definitely do not want 10000 settable knobs
that randomly break things. OTOH per-architecture different randomness
seems like good idea. And if Oracle breaks, fix it.
> - Disable PF_RANDOMIZE for the binary. (Already doable)
> - Decrease randomization system-wide. (My patch lets you do this)
> - Decrease randomization for the binary to a point where it works.
> (Adding SELinux hooks and policy to my patch would allow this)
Which immediately makes your patch obsolete.
> Disabling randomization for the binary is much more fine-grained, but
> opens up that binary for attacks. Oracle breaks with high-order
> entropy; we can disable randomization on Oracle and keep high-order
> entropy, but now the database server is at risk. This isn't the
> greatest idea in the world either.
So fix Oracle. No need to invent serious infrastructure because Oracle
is broken.
> It appears to me that the best solution is per-policy, but we should
> leave even that up to the user. This means make a sane default--
> one
No. Current situation is okay as is. It does not need to be
configurable, and it should not be.
Per-architecture ammount of randomness would be welcome, I
believe. That will force Oracle to fix their code, but that's okay,
and you can use disable PF_RANDOMIZE for Oracle in meantime.
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Pavel Machek wrote:
> Hi!
>
>>>>>> On the other hand, some things[1][2][3] may give us the undesirable
>>>>>> situation where-- even on an x86-64 with real NX-bit love-- there's an
>>>>>> executable stack. The stack randomization in this case can likely be
>>>>>> weakened by, say, 8 bits by padding your shellcode with 1-byte NOPs
>>>>>> (there's a zillion of these, like inc %eax) up to 4096 bytes. This
>>>>>> leaves 1 success case for every 2047 fail cases.
>>>>> Maybe we can add more bits of randomness when there's enough address
>>>>> space -- like in x86-64 case?
>>>> Yes but how many? I set the max in my working copy (by the way, I
>>>> patched it into Ubuntu Dapper kernel, built, tested, it works) at 1/12
>>>> of TASK_SIZE; on x86-64, that's 128TiB / 12 -> 10.667TiB -> long_log2()
>>>> - -> 43 bits -> 8TiB of VMA, which becomes 31 bits mmap() and 39 bits stack.
>>>>
>>>> That's feasible, it's nice, it's fregging huge. Can we justify it? ...
>>>> well we can't justify NOT doing it without the ad hominem "We Don't Need
>>>> That Because It's Not Necessary", but that's not the hard part around here.
>>> Well, making it configurable and pushing hard decision to the user is
>>> not right approach, either. I believe we need different
>>> per-architecture defaults, not "make user configure it".
>> Yes, different per-architecture defaults is feasible with configuration
>> being possible. I could replace 'int STACK_random_bits=19' with 'int
>> mmap_random_bits=ARCH_STACK_RANDOM_BITS_DEFAULT' and that would be
>> effective as long as the user doesn't touch it with command line or
>> SELinux or whatnot.
>>
>> It is still possible that ARCH_STACK_RANDOM_BITS_DEFAULT breaks things.
>> The current kernel default broke emacs at first I heard; I believe
>> we
>
> Well, fix emacs then. We definitely do not want 10000 settable knobs
> that randomly break things. OTOH per-architecture different randomness
> seems like good idea. And if Oracle breaks, fix it.
>
Fix this, fix that. In due time perhaps. I'm pretty sure Linus isn't
going to break anything, esp. since his mail client breaks too.
>> - Disable PF_RANDOMIZE for the binary. (Already doable)
>> - Decrease randomization system-wide. (My patch lets you do this)
>> - Decrease randomization for the binary to a point where it works.
>> (Adding SELinux hooks and policy to my patch would allow this)
>
> Which immediately makes your patch obsolete.
How so? My patch (the current fourth-generation copy I have here)
supplies effective infrastructure that makes it easy to change
per-architecture randomization or adjust randomization as per policy.
Currently all you can do is flip off PT_GNU_STACK to kill randomization
entirely; or live with the kernel defaults. I'm progressing towards the
third bullet point above.
>
>> Disabling randomization for the binary is much more fine-grained, but
>> opens up that binary for attacks. Oracle breaks with high-order
>> entropy; we can disable randomization on Oracle and keep high-order
>> entropy, but now the database server is at risk. This isn't the
>> greatest idea in the world either.
>
> So fix Oracle. No need to invent serious infrastructure because Oracle
> is broken.
Yeah we tried this one already. Linus said no. Arjan said no. They're
not insane, even though the people running Oracle on anything less than
a 64-bit server are (3GiB TASK_SIZE for a database server juggling
multi-gigabyte databases? No thank you).
>
>> It appears to me that the best solution is per-policy, but we should
>> leave even that up to the user. This means make a sane default--
>> one
>
> No. Current situation is okay as is. It does not need to be
> configurable, and it should not be.
>
My issue is I want *more* randomization. Linus won't give me more,
because it breaks Oracle/Emacs/some mail client/etc. Over here I'm
running Ubuntu Dapper i386 on my laptop out of the box with the kernel
patched with 24 bits stack and 16 bits mmap() randomization fine
(default is 19 and 8); but I'm not running any of the handful of apps
that break.
Why should it NOT be configurable anyway? If you don't configure it,
then it behaves just like it would if it wasn't configurable at all.
This is called "having sane defaults."
There's different people with different wants and needs. I'm sure if
you look hard enough you'll find a group of people who want 256M stack
and 256M mmap() randomization on i386 (hint: Adamantix, Hardened
Gentoo, anyone who swears by grsecurity); equally, if you look you'll
find people who feel 8M stack and 1M mmap() is fine even on x86-64
(hint: Linus, Arjan, Fedora/RedHat).
You'll also find those of us who don't particularly care about tangible
benefit, and will crank up the protection on mathematical figures
provided there are no detrimental effects. This would be me; nobody
comes near my house at night, in my whole life nobody has ever tried to
jigger with my door, it'd be 'safe' to leave it unlocked at night but I
still lock it. Why? Because I get the reasonable guarantee that
someone isn't going to just walk into my house with the twist of a knob,
and the only cost is turning a little piece of metal 90 degrees twice a
day (with the proper lock it can even be pushing a button to lock, and
the door automatically unlocks when I turn the knob from the inside).
It's not 16 unevenly keyed deadbolts I lock and unlock every time I open
my door.
Still, there's some merit to the argument:
Attacks using our technique need only guess the libc text segment
offset, reducing the search space to an entirely practical 16 bits.
While our specific attack uses only a single entry-point in libc, the
exploit technique is also applicable to chained return-to-libc
attacks.
Our implementation shows that buffer overfl ow attacks (as used by,
e.g., the Slammer worm [11]) are as effective on code randomized by
PaX ASLR as on non-randomized code. Experimentally, our attack takes
on the average 216 seconds to obtain a remote shell.
-- http://www.stanford.edu/~blp/papers/asrandom.pdf
(Now you know where I keep quoting 216 seconds from)
The paper works on 16 bits of randomization-- 256M of mmap()
randomization that PaX applies. At a glance, it doesn't seem to take
into account finding the stack frames injected into the stack or heap--
both of which PaX and FC5's Exec Shield randomize the base of, and of
which mainline Linux randomizes the stack base on.
I would say that possibly randomization can be decreased by 1 to 1.5
bits with the assumption that the injected stack frames are about a page
long-- realisticly however, we could probably align system() pages to 32
or 48 bytes, knocking off 6-7 bits. We're almost back to page-aligned
stack here, so let's use that assumption.
Right now we have 8 bits mmap() (1M) and 19 bits stack (8M), which we
can reduce to 8 and 11, total 19 bits for an attacker. Assuming the
above report gives an accurate view of brute forcing i.e. Apache, we
just increased the complexity by 3 orders of magnitude-- should average
1728 seconds, or about 29 minutes. This is still my sysadmin's lunch
break and nobody else is going to notice we're under attack.
If we increase to 16 bits mmap() (256M) and 24 bits stack (256M), which
can reduce to 16 and 16, this totals 32 bits for an attacker. Under the
same assumptions, this is 16 orders of magnitude bigger (2^16 == 65536),
216 * 2^16 == 14,155,776 seconds (164 days). This is about a 5 month
vacation for my sysadmin.
Like I said before, though, massive randomization breaks Oracle at
least, possibly other things. We can't just slap it across the board here.
Interestingly, if we get this to an executable stack and shellcode
inject, 19 bits becomes 11 bits and our attack is 5 orders of magnitude
easier -- 216 / 2^5 == 6.75 seconds. With 24 bits we can make it 16
bits, so it's still 216 seconds. (Do you feel like sub-page
randomization is just about useless yet? Not quite, but almost? It's
more effective on ret2libc chaining attacks..)
So our absolute worst case is 7 seconds and we can make it about 3 and a
half minutes on i386. If we have an NX stack-- which by the way SELinux
CAN enforce now (breaks Metacity on Fedora Core 5, but everything else
works; the policy could be changed here until someone fixes
Metacity..)-- then we move our worst case from 29 minutes to 164 days.
If we do this, however, we break things; and we can't just slap this
into the kernel and say "DURR FIX UR SHIT!"
> Per-architecture ammount of randomness would be welcome, I
> believe. That will force Oracle to fix their code, but that's okay,
> and you can use disable PF_RANDOMIZE for Oracle in meantime.
No, this would leave Oracle shipping binaries with PF_RANDOMIZE
(PT_GNU_STACK still?) disabled. Also if PF_RANDOMIZE is still connected
to PT_GNU_STACK, then this means that randomization is turned off BY
MAKING THE STACK EXECUTABLE. You should notice the obvious problem
here. You should also understand that as long as they can simply switch
randomization off, they're not going to fix it; and as long as it breaks
Oracle/Emacs/anything, Linus is not going to impose non-disablable,
non-adjustable randomization.
> Pavel
- --
All content of all messages exchanged herein are left in the
Public Domain, unless otherwise explicitly stated.
Creative brains are a valuable, limited resource. They shouldn't be
wasted on re-inventing the wheel when there are so many fascinating
new problems waiting out there.
-- Eric Steven Raymond
We will enslave their women, eat their children and rape their
cattle!
-- Bosc, Evil alien overlord from the fifth dimension
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2.2 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iQIVAwUBRHH6zgs1xW0HCTEFAQLPMg//WTW47tVb1Xk7aQQ5kF0CWO3MjU/kE5rw
4M7kHd2sb1qGDYUIWIx1jIUAb4ce8AYFqPYEtMpeiqFics0nwK30E/U4BKxwcmzl
+bd8bNhfWY4aTGM+L6dzlW2CmKGotNtLZb2iwbRhfNpEeFHJHGCiANd82SLFmJbY
zT15qm+14O4TR9E0LHEHHQYIu2wCksv5dEG49dtUJqdf2MP4Zy66ZmVShUZOCtrq
Fbl4cZYqJO0qAbZL8tz+3VWIvLqDNcuVXZY4gQK1UB4Fp/3gV32OSc/hYDt+LD5F
xDcllnHW65bu+EknPyOO8e6/dorELsvfhfTckj361k8Q3ZcEdB2+W/+Nob03VTCL
I20CEQu4bcl+B7KxP8Y7y54FzC04gZ3og7ce0l6l6H/V0kZfQ6KXb9zfL/P/hIOM
+eKN1QEMdQDP9IkkFhUhu5MmDJeCS9FyApW5cw+erZWC/gNAzjJNSaZp3V/C6U0J
oLUDfah81tOrnHXATVhHCy+V3b+hu7WZM+baWwslkUYoq6uUd7a6knJK6wMVQhnz
BszM4wbxVLlYpPf/8SuxFiUpOHqGfbMjCVYtUW3y8zZ60HGP0ehzbQMMHY4LVZqt
zN95n6DF4nYn0SqwkSvZEOgtTX60AOqTP9QKMbpVgKyoTAH3TOE7kAxWwLUzuDHT
Cz8gA3ga0S0=
=K1fe
-----END PGP SIGNATURE-----
Hi!
> > Well, fix emacs then. We definitely do not want 10000 settable knobs
> > that randomly break things. OTOH per-architecture different randomness
> > seems like good idea. And if Oracle breaks, fix it.
>
> Fix this, fix that. In due time perhaps. I'm pretty sure Linus isn't
> going to break anything, esp. since his mail client breaks too.
Good. So fix emacs/oracle/pine, and year or so and some time after it
is fixed, we can change kernel defaults. That's still less bad than
having
[ ] Break emacs
in kernel config.
> Why should it NOT be configurable anyway? If you don't configure it,
> then it behaves just like it would if it wasn't configurable at all.
> This is called "having sane defaults."
Because if it is configurable, someone _will_ configure it wrong, and
then ask us why it does not work.
And if it is configurable, applications will not get fixed for
basically forever.
> > Per-architecture ammount of randomness would be welcome, I
> > believe. That will force Oracle to fix their code, but that's okay,
> > and you can use disable PF_RANDOMIZE for Oracle in meantime.
>
> No, this would leave Oracle shipping binaries with PF_RANDOMIZE
> (PT_GNU_STACK still?) disabled. Also if PF_RANDOMIZE is still connected
> to PT_GNU_STACK, then this means that randomization is turned off BY
> MAKING THE STACK EXECUTABLE. You should notice the obvious problem
> here. You should also understand that as long as they can simply switch
> randomization off, they're not going to fix it; and as long as it breaks
> Oracle/Emacs/anything, Linus is not going to impose non-disablable,
> non-adjustable randomization.
I believe that Linus is going to apply this one even less likely.
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Pavel Machek wrote:
> Hi!
>
>>> Well, fix emacs then. We definitely do not want 10000 settable knobs
>>> that randomly break things. OTOH per-architecture different randomness
>>> seems like good idea. And if Oracle breaks, fix it.
>> Fix this, fix that. In due time perhaps. I'm pretty sure Linus isn't
>> going to break anything, esp. since his mail client breaks too.
>
> Good. So fix emacs/oracle/pine, and year or so and some time after it
> is fixed, we can change kernel defaults. That's still less bad than
> having
>
> [ ] Break emacs
>
> in kernel config.
Nobody is going to fix emacs/oracle/pine, they don't have to. Nothing
is making them. The kernel will wait for them so who cares.
>
>> Why should it NOT be configurable anyway? If you don't configure it,
>> then it behaves just like it would if it wasn't configurable at all.
>> This is called "having sane defaults."
>
> Because if it is configurable, someone _will_ configure it wrong, and
> then ask us why it does not work.
Oh big deal. People configure out ide drivers and ask why their kernel
doesn't boot all the time. Distro maintainers do most of the work.
This is a weak argument, bordering FUD. It's the same argument as
everything else, except we just said, "Well not really important"
everywhere else.
>
> And if it is configurable, applications will not get fixed for
> basically forever.
FUD. If it's not configurable, applications will not get fixed for
basically forever, and nobody will put the breaking code into mainline.
Linus is NOT giving 256M/256M randomization on mainline as default ever.
>
>>> Per-architecture ammount of randomness would be welcome, I
>>> believe. That will force Oracle to fix their code, but that's okay,
>>> and you can use disable PF_RANDOMIZE for Oracle in meantime.
>> No, this would leave Oracle shipping binaries with PF_RANDOMIZE
>> (PT_GNU_STACK still?) disabled. Also if PF_RANDOMIZE is still connected
>> to PT_GNU_STACK, then this means that randomization is turned off BY
>> MAKING THE STACK EXECUTABLE. You should notice the obvious problem
>> here. You should also understand that as long as they can simply switch
>> randomization off, they're not going to fix it; and as long as it breaks
>> Oracle/Emacs/anything, Linus is not going to impose non-disablable,
>> non-adjustable randomization.
>
> I believe that Linus is going to apply this one even less likely.
Apply what? It's already like that. The kernel is set to be able to
switch randomization off based on a header in the binary. That header,
as of 2.6.12, was PT_GNU_STACK if I recall correctly; this same header
switches the stack to non-executable. Unless Linus accepted a patch to
follow ANOTHER field, and upstream binutils has changed it, and all
distributions have reflexed to use the new toolchain, it's still like this.
>
> Pavel
- --
All content of all messages exchanged herein are left in the
Public Domain, unless otherwise explicitly stated.
Creative brains are a valuable, limited resource. They shouldn't be
wasted on re-inventing the wheel when there are so many fascinating
new problems waiting out there.
-- Eric Steven Raymond
We will enslave their women, eat their children and rape their
cattle!
-- Bosc, Evil alien overlord from the fifth dimension
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2.2 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iQIVAwUBRHIKyQs1xW0HCTEFAQJMVQ//WM+FqtIvJZdNFhbISZAcdQbklYVYtZds
oo+ea2/lgD+4JDTDUWVphlsyjiCHL+7QMGSQJ2t6WMFBOPFyKlW98/Q9TYksAady
cDkVecY1XJ/iLaRnOoxu+GlZFVkNARG50bYVTkbWnNiHZezu1c8kZ7p/0XrlkxEl
zDql/0281vE6/pkGAnRsgaCCGPZVYAtq06zteCIIdcb+UIoRssOpCZb8ldDGQKGw
Kw3Lguc7ynJCOS9eS2rm92aq+Mh/XC7SEb7VJu5H5lTjAkMJVVvDvE0C+BJ+lFuc
uaU8zjkhLBrYHu1jsHpDwCkrGf0jIhjjctfNaWfab6rW92JrcNpY+Jp+nGPz67x/
DxAG3ZPcQA/o+ltaVdcGFYPcDPhJ0soXrtVAjBAe5NnbE606ELnhTq2d85n8ZWBh
7SxDEN9pIyyFfVbvs0TubUC/5icb7Y4Bn1c3PoUKO4HHaSkKvIp5jWvd6daaD57d
AqeaSqSXU+Hs5reXL2hLV+C0/wTKggs6bsapu3P8/pETgr8/odsX3wAUz6YVfvI1
vF9ybN3kNYJTNoGpFoCH4buUJJBsXIhLLfautcb9d2mJ0j2kwm4CQOInyob4Tp/A
k8WYKSwlKuKSsgCdQinjjEDAqKs8GOVO7OO/nw1se7yCKHsTFC3Wc4or8iWMyyiP
IBKcRKkSzIg=
=iyBd
-----END PGP SIGNATURE-----
Hi!
> >>> Well, fix emacs then. We definitely do not want 10000 settable knobs
> >>> that randomly break things. OTOH per-architecture different randomness
> >>> seems like good idea. And if Oracle breaks, fix it.
> >> Fix this, fix that. In due time perhaps. I'm pretty sure Linus isn't
> >> going to break anything, esp. since his mail client breaks too.
> >
> > Good. So fix emacs/oracle/pine, and year or so and some time after it
> > is fixed, we can change kernel defaults. That's still less bad than
> > having
> >
> > [ ] Break emacs
> >
> > in kernel config.
>
> Nobody is going to fix emacs/oracle/pine, they don't have to. Nothing
> is making them. The kernel will wait for them so who cares.
No, _you_ have to fix emacs/oracle/pine. You claimed your patch is
interesting for secure distros, so you obviously have manpower for
that, right?
> >> Why should it NOT be configurable anyway? If you don't configure it,
> >> then it behaves just like it would if it wasn't configurable at all.
> >> This is called "having sane defaults."
> >
> > Because if it is configurable, someone _will_ configure it wrong, and
> > then ask us why it does not work.
>
> Oh big deal. People configure out ide drivers and ask why their kernel
> doesn't boot all the time. Distro maintainers do most of the work.
As you may have noticed, I'm at receiving end of those bug
reports. And what you propose is actually *worse* than IDE, because at
least you get relatively clear error message when misconfiguring IDE.
> > And if it is configurable, applications will not get fixed for
> > basically forever.
>
> FUD. If it's not configurable, applications will not get fixed for
> basically forever, and nobody will put the breaking code into mainline.
> Linus is NOT giving 256M/256M randomization on mainline as default
> ever.
For x86-64... why not?
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Pavel Machek wrote:
> Hi!
>
>>>>> Well, fix emacs then. We definitely do not want 10000 settable knobs
>>>>> that randomly break things. OTOH per-architecture different randomness
>>>>> seems like good idea. And if Oracle breaks, fix it.
>>>> Fix this, fix that. In due time perhaps. I'm pretty sure Linus isn't
>>>> going to break anything, esp. since his mail client breaks too.
>>> Good. So fix emacs/oracle/pine, and year or so and some time after it
>>> is fixed, we can change kernel defaults. That's still less bad than
>>> having
>>>
>>> [ ] Break emacs
>>>
>>> in kernel config.
>> Nobody is going to fix emacs/oracle/pine, they don't have to. Nothing
>> is making them. The kernel will wait for them so who cares.
>
> No, _you_ have to fix emacs/oracle/pine. You claimed your patch is
> interesting for secure distros, so you obviously have manpower for
> that, right?
RHAT probably fixed Emacs already since it broke on them. Adamantix and
Hardened Gentoo are most likely to put manpower into things like pine..
they put a lot of work into removing textrels on i386.
Oracle we can't do anything about. It's commercial. If we break it,
they will recommend running it on Solaris or Windows 2003.
>
>>>> Why should it NOT be configurable anyway? If you don't configure it,
>>>> then it behaves just like it would if it wasn't configurable at all.
>>>> This is called "having sane defaults."
>>> Because if it is configurable, someone _will_ configure it wrong, and
>>> then ask us why it does not work.
>> Oh big deal. People configure out ide drivers and ask why their kernel
>> doesn't boot all the time. Distro maintainers do most of the work.
>
> As you may have noticed, I'm at receiving end of those bug
> reports. And what you propose is actually *worse* than IDE, because at
> least you get relatively clear error message when misconfiguring IDE.
>
Yes but when you misconfigure IDE the system doesn't boot. When you
turn up randomization too high, everything works but 1 or 2 programs.
You bitch to your distro or to the upstream programmer and they tell you
"It won't function like that, do this" or "We don't know right now" and
you make the connection and turn it back down or wind up here.
If you get that far, at least you know what you did and how to undo it.
>>> And if it is configurable, applications will not get fixed for
>>> basically forever.
>> FUD. If it's not configurable, applications will not get fixed for
>> basically forever, and nobody will put the breaking code into mainline.
>> Linus is NOT giving 256M/256M randomization on mainline as default
>> ever.
>
> For x86-64... why not?
On x86-64 he may, if you can convince him it's useful (asserting that
turning entropy up on i386 is non-useful is not a good start hinthint).
On i386 or other 32-bit where TASK_SIZE is a few GiB, no chance in
hell, but it'd be nice to be able to tweak it upwards if desired.
>
- --
All content of all messages exchanged herein are left in the
Public Domain, unless otherwise explicitly stated.
Creative brains are a valuable, limited resource. They shouldn't be
wasted on re-inventing the wheel when there are so many fascinating
new problems waiting out there.
-- Eric Steven Raymond
We will enslave their women, eat their children and rape their
cattle!
-- Bosc, Evil alien overlord from the fifth dimension
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2.2 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iQIVAwUBRHIQsQs1xW0HCTEFAQK8rw/+O63a9cVnA+eth3lXRlXPfX/Bi3VEu9QL
ELk3IRw6iN2upFMY7HMcxoec4qLpx52yaqFWepUU9DWPgvmwq/GSM0XNDJ1SRQTc
N/yAKvHsfcir4Y/MIn5byWMSEGUbUIokMmOGUlWLICQCTMBSo7AQGmoXQnLP/kNP
6b2jqXWGVoT+4nDPAi0rItO+g+YWrV8Nnx4BTS9SsiRrcAt7F2PsqrnScSRlRV49
2n4WjFkrFhb89173qEew760ZsBuMpM0q+vY203zclVvaS4Oh/mlZuPN98iOaG182
9PE3AtSJAhj6uUuaIsxsxNsO17OwpsVXniIKiogD7Z0Wqfjzp/+tIGMXXB0JoF8j
+88uLTUywCqYeKViUuyhzdMoBYN3aKPzx0Ye/m6PoILH5QbsfR3trGiec7bP/jeN
wsMi4LdmnkOu6y96liwyIiyNS4bGQUa0rroI/XreUT/HJOqIC0kwDhDwKze2m91o
bN8K4ZmD2KW/zPvUQn5Atp36UdD8fu3UER1b1ecS0gtf3HOvJvaEXoyileFNHZcg
7QD88daKOY8WI+Yi2ZsQBr+j9IZzPsNhpXwaEozfLSjm0AfsgY7rJtwIioZMMNxy
wWLp/myHU0cYQTr6UADV2Mb10GxvMBkwluGiFPMgUu2qh7MSHPJq2qhjlJiCPWij
pnqRL7cPcDs=
=9G6c
-----END PGP SIGNATURE-----
Hi!
> >>> Good. So fix emacs/oracle/pine, and year or so and some time after it
> >>> is fixed, we can change kernel defaults. That's still less bad than
> >>> having
> >>>
> >>> [ ] Break emacs
> >>>
> >>> in kernel config.
> >> Nobody is going to fix emacs/oracle/pine, they don't have to. Nothing
> >> is making them. The kernel will wait for them so who cares.
> >
> > No, _you_ have to fix emacs/oracle/pine. You claimed your patch is
> > interesting for secure distros, so you obviously have manpower for
> > that, right?
>
> RHAT probably fixed Emacs already since it broke on them. Adamantix and
> Hardened Gentoo are most likely to put manpower into things like pine..
> they put a lot of work into removing textrels on i386.
>
> Oracle we can't do anything about. It's commercial. If we break it,
> they will recommend running it on Solaris or Windows 2003.
Well, if RedHat ships randomization, it will make Oracle fix it quite
quickly :-).
> > As you may have noticed, I'm at receiving end of those bug
> > reports. And what you propose is actually *worse* than IDE, because at
> > least you get relatively clear error message when misconfiguring IDE.
>
> Yes but when you misconfigure IDE the system doesn't boot. When you
> turn up randomization too high, everything works but 1 or 2
> programs.
Yes, you'll very quickly realize you misconfigured IDE... while stack
randomization is going to break 2 apps and you'll not know why.
> > For x86-64... why not?
>
> On x86-64 he may, if you can convince him it's useful (asserting that
I do not care much about randomization, sorry. I see it may be useful
on x86-64, but I do not think configurability helps. Sorry.
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Pavel Machek wrote:
> Hi!
>
>>>>> Good. So fix emacs/oracle/pine, and year or so and some time after it
>>>>> is fixed, we can change kernel defaults. That's still less bad than
>>>>> having
>>>>>
>>>>> [ ] Break emacs
>>>>>
>>>>> in kernel config.
>>>> Nobody is going to fix emacs/oracle/pine, they don't have to. Nothing
>>>> is making them. The kernel will wait for them so who cares.
>>> No, _you_ have to fix emacs/oracle/pine. You claimed your patch is
>>> interesting for secure distros, so you obviously have manpower for
>>> that, right?
>> RHAT probably fixed Emacs already since it broke on them. Adamantix and
>> Hardened Gentoo are most likely to put manpower into things like pine..
>> they put a lot of work into removing textrels on i386.
>>
>> Oracle we can't do anything about. It's commercial. If we break it,
>> they will recommend running it on Solaris or Windows 2003.
>
> Well, if RedHat ships randomization, it will make Oracle fix it quite
> quickly :-).
RHAT ships the same mmap() and stack randomization mainline does; plus
heap randomization. paxtest claims RHAT does something like 1 or 2 more
bits of mmap() randomization than mainline does on i386 as of FC5; but
that regression test in paxtest is a bit flakey. It nails the stack
randomization dead on.
I think if RHAT did break Oracle, Oracle would just ship with
PT_GNU_STACK, which enables an executable stack (!) and disables stack
and mmap() randomization (!!). Who would notice anyway? Maybe auditors
looking at every flag set on every binary on the system.
Now, if RHAT had to write SELinux policy, and upped randomization to
better protect Apache, but had to explicitly keep it low for Oracle,
that would be very transparent to the RHAT developers and to policy
auditors. Would anyone notice? Probably not.
If RHAT FORCED Oracle to use higher randomization, it would break.
Oracle Inc. would then recommend against using RHAT, instead advising
the use of Solaris or Win2k3. Why? It's easier to advise migration
than fix code, especially when you can point out exactly what the
platform you broke on changed and prove that it's not really your fault.
>
>>> As you may have noticed, I'm at receiving end of those bug
>>> reports. And what you propose is actually *worse* than IDE, because at
>>> least you get relatively clear error message when misconfiguring IDE.
>> Yes but when you misconfigure IDE the system doesn't boot. When you
>> turn up randomization too high, everything works but 1 or 2
>> programs.
>
> Yes, you'll very quickly realize you misconfigured IDE... while stack
> randomization is going to break 2 apps and you'll not know why.
It's a command line option. It happens as soon as you change menu.lst
or lilo.conf or screw with the command line at boot time. Do you want
me to write some kind of Documentation/address-randomization.txt
explaining it?
Remember in the future I want to buff out the command line option (two
short functions, just delete them outright along with the __setup()
below them) for SELinux policy controls. The impacts and possible
problems could be documented right in the SELinux policy controls.
At the very least a user has to do some digging to find out these are
there; then he has to determine what they do and figure out if this is a
good thing. Writing right in the documents, "Turning entropy up too
high may cause certain programs to segfault," will place the more timid
users in a "Let's not touch this" state most of the time; if it doesn't,
they're the ones that break something we warned them would break and
then ask us about it anyway.
>
>>> For x86-64... why not?
>> On x86-64 he may, if you can convince him it's useful (asserting that
>
> I do not care much about randomization, sorry. I see it may be useful
> on x86-64, but I do not think configurability helps. Sorry.
> Pavel
- --
All content of all messages exchanged herein are left in the
Public Domain, unless otherwise explicitly stated.
Creative brains are a valuable, limited resource. They shouldn't be
wasted on re-inventing the wheel when there are so many fascinating
new problems waiting out there.
-- Eric Steven Raymond
We will enslave their women, eat their children and rape their
cattle!
-- Bosc, Evil alien overlord from the fifth dimension
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2.2 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iQIVAwUBRHIZkws1xW0HCTEFAQL2wQ//cskwzR3MsjHB+roSCnrTX+aisLqSu4Cp
c5LzEz3blmD3ETszWXdVLQLu8UBH/U6FXv7mR63ugxcRTnfEHrR3/qRWgTlCRRnE
AT+qJvud9hAWaToIUHRn5MX9uLHc/iXGkR5XCeadNK+liR9EQZP2R0V52HjUoag7
2JfL1+4xRQ7A7gRDLzR6P7JgQq2rZ0fUWtSoxsnZtBE8ZSbkSjobBUxDhTHW1x5z
1c4ChuGV4LJgbGdL8RNgpC1fjrkhGrhH6avTLV49rsvweAf5+ABKsIrHXo1eT3FO
aO5R8F8RigHjdNhWtvia6ehAo0IL836x3duxSPOqUawxGUa9RycyC6URAwePDJK4
kQ8xJ/fWs6DmSEEnijPnN+qfObX7sjA3U1fXy74DN3DnS+8SvM3I/N8Ay3sUvVBh
IGKl8hBfa2WNex+KEWWNdu608z7gyRiMnIOq433B2YezHpT3PhtsBdL83zcZ8IqG
VTPo/rA5aCxgzD0jaSqBWq1skaVxyk3RsOd/ddPpDIbZ5FPaSYRD2NzkRHTasTMv
08gv/pjNxPHQb6YSszjX+yCrr1eiAkBDtSO5egCC47LGWKyPv2Cw8+2j47B34BVQ
5X6GhBHlm1Tm+wV0eYhpaw1+8ZJEKLdEM8llrUiTfYtrsvuIyu8+aVUyteF8nwCl
N3iYliYUDNw=
=zNfh
-----END PGP SIGNATURE-----
On Mon, 2006-05-22 at 12:31 -0400, John Richard Moser wrote:
> It is still possible that ARCH_STACK_RANDOM_BITS_DEFAULT breaks things.
> The current kernel default broke emacs at first I heard;
hearsay.. where did you hear this and what exact randomization was this?
> I believe we
> started with 64KiB of stack randomization and then upped it to 8MiB when
> emacs was fixed.
this is new information to me, I find this really really hard to believe
as true but maybe you have information I don't have...
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Arjan van de Ven wrote:
> On Mon, 2006-05-22 at 12:31 -0400, John Richard Moser wrote:
>> It is still possible that ARCH_STACK_RANDOM_BITS_DEFAULT breaks things.
>> The current kernel default broke emacs at first I heard;
>
> hearsay.. where did you hear this and what exact randomization was this?
>
Sorry, I googled it, you were talking about brk() randomization (which I
STILL want to see! :D)
http://lkml.org/lkml/2005/1/28/29
>
>> I believe we
>> started with 64KiB of stack randomization and then upped it to 8MiB when
>> emacs was fixed.
>
> this is new information to me, I find this really really hard to believe
> as true but maybe you have information I don't have...
See this is why I said "I believe..." :)
>
>
>
>
- --
All content of all messages exchanged herein are left in the
Public Domain, unless otherwise explicitly stated.
Creative brains are a valuable, limited resource. They shouldn't be
wasted on re-inventing the wheel when there are so many fascinating
new problems waiting out there.
-- Eric Steven Raymond
We will enslave their women, eat their children and rape their
cattle!
-- Bosc, Evil alien overlord from the fifth dimension
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2.2 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iQIVAwUBRHJmpQs1xW0HCTEFAQLX9Q//Rm0CvdLkPSq0UCLot9Mqyuj4REVwaGrV
VwJOGJgElyE/RFqu5MI8ab8CV7WUgKiV/wWrxyrfXRpW4uuYbedIsXAw8tzlJq/c
o+4FLVQBS+cXJ96VXIsHLIConlF21pXBZDzBFHHwfSsUsmbvgeJ0WavC3x3N7y6B
Bq4/RfVmf6yEECGSemoApzpbMR01anK6/nc1t0P9iMpsK5tlE9Q7r4/pB3wyRVmY
66GKAbcC4gU9CHtuu2e158/FCQXcfVZ1nFvKWGZyPWGAZAEiGazrMM5iv962EHX3
bqHKcMhr6BxsQt6LG7jzplg6YMDppqqWtiiIUfVJSnW65k1a2AmdGAEi0ZIe7IDm
T/YJRJqi54NOcI+UJ4FcODdlxfZ2EiVXNY22sf9wpn1lQpWt1TX4pbsaHjHVlLB7
8pBQzHSD+P9rDJ0eXfAC+0Vi0V/K1Yna/qhtdEnX2pp08zc2rdC6hu466MGWsH1u
vzD4772nWekd/c9Yby2BXbq+lwXHNA5iIwLBPA/NQwmSENFCdYhIFSrIOBjctQ1W
u85q3dhtFfXhTdwRdjfYtpoiYGIDx4l0wUohHPNLh5sD7NC81EtDOHm/WZfx2C1G
NAWsWkDPntxUpUcuSm+3nl3zDoPYPSMRiztwbWvm0BEdpn2uDyO0v5fMWdenpvMN
sn7wkuMaTlQ=
=OLQP
-----END PGP SIGNATURE-----