Re: [RFC][PATCH 7/7] kref: Implement using refcount_t

[Ingo Molnar]

* Kees Cook <keescook@xxxxxxxxxxxx> wrote:

> On Tue, Nov 15, 2016 at 11:16 AM, Peter Zijlstra <peterz@xxxxxxxxxxxxx> wrote:
> >
> >
> > On 15 November 2016 19:06:28 CET, Kees Cook <keescook@xxxxxxxxxxxx> wrote:
> >
> >>I'll want to modify this in the future; I have a config already doing
> >>"Bug on data structure corruption" that makes the warn/bug choice.
> >>It'll need some massaging to fit into the new refcount_t checks, but
> >>it should be okay -- there needs to be a way to complete the
> >>saturation, etc, but still kill the offending process group.
> >
> > Ideally we'd create a new WARN like construct that continues in kernel space 
> > and terminates the process on return to user. That way there would be minimal 
> > kernel state corruption.

Yeah, so the problem is that sometimes you are p0wned the moment you return to a 
corrupted stack, and some of these checks only detect corruption after the fact.

> Right, though I'd like to be conservative about the kernel execution 
> continuing... I'll experiment with it.

So what I'd love to see is to have a kernel option that re-introduces some 
historic root (and other) holes that can be exploited deterministically - 
obviously default disabled.

I'd restrict this to reasonably 'deterministic' holes, and the exploits themselves 
could be somewhere in tools/. (Obviously only where the maintainers agree to host 
the code.) They wouldn't give a root shell, they'd only test whether they reached 
uid0 (or some other elevated privilege).

The advantages of such a suite would be:

 - Uptodate tests on modern kernels: It would allow the (controlled) testing of 
   live kernel exploits even on the latest kernel - and would allow the testing of 
   various defensive measures.

 - It would also make sure that defensive measures _remain_ effective against 
   similar categories of bugs. We've had defensive measure regressions in the 
   past, which was only discovered when the next exploit came out ...

 - Testing of new defensive measures: It would help convert this whole 
   probabilistic and emotion driven "kernel protection" business into something 
   somewhat more rational. For example new protection mechanisms should have a 
   demonstrated ability to turn an existing exploit test into something less 
   dangerous.

 - Education: It would teach kernel developers the various patterns of holes, 
   right in the code. Maybe being more directly exposed to what can get you p0wned 
   is both a stronger education force plus it could give people ideas about how to 
   protect better.

 - I also think that collecting the various problems into a single place will give 
   us new insights into patterns, bug counts and various exploit techniques.

The disadvantages would be:

 - Maintenance: do we want to add extra (compiled out by default) code to the 
   kernel whose only purpose is to demonstrate certain types of bugs?

 - Exposing exploits: Do we want to host a powerful collection of almost-exploits 
   in tools/ ? I don't think we have a choice but to face the problem directly - 
   but others might disagree.

I think most of the negatives could be kept small by starting small, allowing 
maintainers to explicitly opt-in, and observing the effects as we go. But YMMV.

Thanks,

	Ingo