Re: [RFC][PATCH] linux-2.6.2-rc2_vsyscall-gtod_B1.patch

[Andrea Arcangeli]

On Fri, Feb 06, 2004 at 10:37:59PM -0500, Daniel Jacobowitz wrote:
> On Sat, Feb 07, 2004 at 03:19:55AM +0100, Andrea Arcangeli wrote:
> > > The official kernel might have the vdso at a fixed address part no part
> > > of the ABI requires this address and so anybody with some security
> > > conscience can change the kernel to randomize the vdso address.  It's
> > > not my or Ingo's fault that Linus doesn't like the exec-shield code
> > > which would introduce the randomization.  The important aspect is that
> > > we can add vdso randomization and nothing else needs changing.  The same
> > > libc will run6 on a stock kernel and the one with the randomized vdso.
> > > This is not the case on x86-64 where the absolute address for the
> > > gettimeofday is used.
> > 
> > I don't know exactly what your "randomization exec-shield" code is doing
> > either. the way I understand what you wrote is that you want to relocate
> > the vsyscall trasparently without glibc knowledge, so in short you're
> > saying that you don't care to randomize everything in the userspace
> > executable address space, you only care to relocate the vgettimeofday
> > bytecode, not the rest of the vsyscall pieces. So with your solution
> > you'll still have "fixed" addresses in the address space that will allow
> > an attacker to execute vgettimeofday, just like glibc can execute it
> > without noticing the actual function was relocated. As far as glibc
> > won't notice that vgettimeofday has been relocated by your
> > "exec-shield", it means the attacker as well can execute it just fine.
> 
> You might want to stop and take a look at the way this works on i386
> before you argue with Ulrich any more about it.
> 
> Specifically, the vsyscall DSO is constructed as a normal ELF image,
> and its base address is passed to glibc as an AT_SYSINFO tag in the
> application's auxv vector.  Glibc source code has absolutely no
> knowledge of the base address, which in fact has changed at least three
> times since it was created.

(changing three times is worthless in terms of security, all computers
runs the same bzImage so it's not changing, anyways as Ulrich said this
can be fixed transparently in "their" kernel)

The idea of randomizing the base address in kernel is not different from
generating it in glibc and asking the kernel to relocate. this mean it
probably won't be an environment variable but a root system wide sysctl
to control the randomization (so I find it less flexible, though it's
probably simpler to implement). But regardless my point is that the last
patch posted by john is not the way to go. glibc should call into a
fixed _offset_, the base address after all doesn't matter much if it's
generated by kernel or glibc, so I don't care if it's the kernel
randomizing, my whole point is that glibc must keep calling
vgettimeofday _direct_ without passing through the vsyscall wrapper
where all the other syscalls are passing through. there is not point to
pass through a wrapper when you can speed it up using a _fixed_ offset.

Glibc needs an hardcoded _fixed_ like in a stone table of offsets (yeah
they're not "addresses" like in x86-64, but still they're fixed and
glibc knows about each vsyscall). If we want to implement it the same
way in x86-64 too (randomizing in kernel and passing down the random
base address from kernel instead of generating it in glibc), it maybe
troublesome for compatibility, however I don't care that much about it,
as far as there is a table of hardcoded like in a stone offsets for each
vsyscall, to call it directly, without a table or wrapper. I preferred
the generation of the address in glibc (where the randomizing code must
already exist to randomize everything else including the .text of the
normally non relocatable binary) that was also backwards compatible, but
this is not the bit I care about. The bit I care about is that glibc
should know about the vsyscall to be efficient, and that the offsets
should be fixed.

And as said the randomization in x86 will be a joke to bruce force so
this randomization issue mostly matters for x86-64.

I'd like to know if people dislikes the mremap for the vsyscalls, and if
they prefer the randomization code duplicated in kernel breaking
backwards compatibility with current production x86-64 glibc.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/