Re: [PATCH 1/9] exec: add a global execve counter

[Solar Designer <solar@openwall.com>]

On Sat, Mar 10, 2012 at 04:58:01PM -0800, Linus Torvalds wrote:
> On Sat, Mar 10, 2012 at 4:36 PM, Linus Torvalds
> <torvalds@linux-foundation.org> wrote:
> >
> > I wonder if the number part of exec_id would even have to be 64-bit. I
> > think I can do about 10000 execves per second if I make the program a
> > small static one - and that's on a fast CPU. And it's a per-thread
> > counter, so you can't scale it with lots of CPU's. So it would take
> > something like four days to wrap. Hmm..
> 
> Actually, using a pure counter is horrible, because even if it takes
> four days to wrap, it *will* wrap, and the attacker can just count his
> own execve's.

Four days (for a 32-bit counter) is just not enough, so the counter
needs to be e.g. 64-bit as proposed.  A 64-bit counter won't wrap during
lifetime of a system.

> If, instead, you were to use a counter that counts *independently* of
> execve's, you're much better off.
> 
> And if you use one that is free - because the CPU implements it
> natively - you're even better off.
> 
> IOW, why is the exec-id just the time stamp counter

The CPUs' timestamp counters were not designed for security.  I would
not be too surprised if some implementation of a CPU architecture (maybe
emulated, maybe under a hypervisor) has such timestamp counter
granularity that we may see the same value across a second execve().

Also, we'd need extra code for archs/CPUs that lack timestamp counters.

> (on any random cpu - we really don't care)?

I'd rather not rely on the timestamp counters across CPUs being in sync,
and if they are not in sync then we may see the same value again (on one
CPU vs. another).  So at least we'd need to record the CPU number as well.

> That should be safe even in just 32 bits
> exactly because it's not under the control of the user.

32 bits is just not enough even if not under control of an attacker.
If there's some low chance of hitting the same counter value on execve()
vs. procfs file access and there's no lockout on multiple counter
mismatches, an attacker may simply try that in a loop, and with 32-bit
values might have a good chance of succeeding in a reasonable amount of
time (such as a few days).

Alexander