[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <201907221004.E8583B5F28@keescook>
Date: Mon, 22 Jul 2019 10:10:46 -0700
From: Kees Cook <keescook@...omium.org>
To: "Gote, Nitin R" <nitin.r.gote@...el.com>
Cc: Vegard Nossum <vegard.nossum@...il.com>,
"kernel-hardening@...ts.openwall.com" <kernel-hardening@...ts.openwall.com>
Subject: Re: Regarding have kfree() (and related) set the pointer to NULL too
On Wed, Jul 17, 2019 at 10:01:21AM +0000, Gote, Nitin R wrote:
> > > -----Original Message-----
> > > From: Kees Cook [mailto:keescook@...omium.org]
> > > Sent: Thursday, June 27, 2019 9:52 PM
> > > To: Vegard Nossum <vegard.nossum@...il.com>
> > > Cc: Gote, Nitin R <nitin.r.gote@...el.com>; kernel-
> > > hardening@...ts.openwall.com
> > > Subject: Re: Regarding have kfree() (and related) set the pointer to
> > > NULL too
> > >
> > > On Thu, Jun 27, 2019 at 01:45:06PM +0200, Vegard Nossum wrote:
> > > > On Thu, 27 Jun 2019 at 12:23, Gote, Nitin R <nitin.r.gote@...el.com>
> > wrote:
> > > > > Hi,
> > > > >
> > > > > I’m looking into “have kfree() (and related) set the pointer to NULL too”
> > > task.
> > > > >
> > > > > As per my understanding, I did below changes :
> > > > >
> > > > > Could you please provide some points on below ways ?
> > > > > @@ -3754,6 +3754,7 @@ void kfree(const void *objp)
> > > > > debug_check_no_obj_freed(objp, c->object_size);
> > > > > __cache_free(c, (void *)objp, _RET_IP_);
> > > > > local_irq_restore(flags);
> > > > > + objp = NULL;
> > > > >
> > > > > }
> > > >
> > > > This will not do anything, since the assignment happens to the local
> > > > variable inside kfree() rather than to the original expression that
> > > > was passed to it as an argument.
> > > >
> > > > Consider that the code in the caller looks like this:
> > > >
> > > > void *x = kmalloc(...);
> > > > kfree(x);
> > > > pr_info("x = %p\n", x);
> > > >
> > > > this will still print "x = (some non-NULL address)" because the
> > > > variable 'x' in the caller still retains its original value.
> > > >
> > > > You could try wrapping kfree() in a C macro, something like
> > > >
> > > > #define kfree(x) real_kfree(x); (x) = NULL;
> > >
> > > Right, though we want to avoid silent double-evaluation, so we have to
> > > do some macro tricks. I suspect the starting point is something like:
> > >
> > > #define kfree(x) \
> > > do { \
> > > typeof(x) *ptr = &(x); \
> > > real_kfree(*ptr); \
> > > *ptr = NULL; \
> > > } while (0)
> > >
> > > However, there are a non-zero number of places in the kernel where
> > > kfree() is used on things that are not simple memory references, like
> > > function return values, or copies of the actual reference:
> > >
> > > kfree(get_my_allocation(foo));
> > >
>
> We have not found any clue or compiler extension on this case to know x
> is value or variable.
Do you mean find a way to detect if this is a function return value?
Yeah, this seems like a needed step.
> There are around 300 such cases in kernel where kfree() is used on function return values.
>
> One proposal is we can refactor the kfree() call by assigning it to local variable so that
> we can overcome the compilation issue (error: lvalue required as unary & operand).
What were you thinking for an implementation? Universally using a local
variable doesn't gain very much (since you're just setting the local
variable NULL, not the one that lives on outside the call to kfree()).
> Please let us know that we should proceed with this proposal or you (or anyone)
> have other proposals.
>
> > > or
> > >
> > > previous = something->allocation;
> > > ...
> > > kfree(previous)
> > >
>
> As of now, we don't have any idea to overcome this case.
> So, we are keeping this for later stage.
It sounds like this may not be possible with the existing APIs -- maybe
a compiler feature is needed to do the variable tracking (and also the
"was this a function return value?" check).
>
> In case anyone has idea on this then let me know,
> we are ready to work on this.
>
> > > So the larger work is figuring out how to gracefully deal with those
> > > using a reasonable API, or through refactoring.
> > >
> > > However, before getting too far, it's worth going though past
> > > use-after-free vulnerabilities to figure out how many would have been
> > > rendered harmless (NULL deref instead of UaF) with this change. Has
> > > this been studied before, etc. With this information it's easier to
> > > decide if the benefit of this refactoring is worth the work to do it.
This part is still worth checking: is there a real-world benefit to this
idea? (It seems like it should make some classes of UAF go away, but
it'd be nice to back this up with some "proof" from existing prior
exploits.)
--
Kees Cook
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
