Kees Cook kees at ubuntu.com
Thu Aug 2 17:10:25 UTC 2012

Hi John,

On Wed, Aug 01, 2012 at 12:47:58PM -0700, John Johansen wrote:
> There are a couple of different vectors to attack creds but I can't see how
> the current DEBUG_CREDENTIALS would stop the attacks, though it would
> possibly make the overwrite attack harder.

It was the "harder" part I was thinking of.

> 1. is a use after free attack. Basically there is an uncounted reference
>    still in use or an extra put ..
>    You exploit it by getting an unprivileged task/object to "free" the
>    cred and getting a privileged task to allocate the freed cred,
>    reinitializing it into a privileged cred.
>    However the debug code will only help in the race window, if the
>    cred is referenced while it is freed. Once it has been reinitialized
>    the cred looks good and the error won't be caught.
> 2. some kind of memory overwrite attack, where the attacker has some
>    limited ability to overwrite the cred. The debug code won't catch
>    most over writes, unless it results in a wrong magic value or
>    the task ref count > than the cred ref count
> At the moment I am leaning towards saying No to turning this on for our
> default kernels, because while the cost is small (noise with the limited
> testing I have done). I don't see it actually stopping most actual
> attacks.
> I will poke some more and hopefully kees can slap some sense into me,
> and make me see what I am missing.

There's not anything more obvious that stands out to me. It just seemed
like an added hurdle to rare cred allocation flaws. Not all kernel
bugs allow arbitrary control over what's being written, so adding the
requirement of the magic + usage counter (at the correct location)
seemed worth it to me to get a small defense.

I won't cry if it's not enabled -- it just seemed like a good trade off
to me.


Kees Cook

More information about the kernel-team mailing list