Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Wed, 10 Nov 2010 09:43:43 -0800
From: Kees Cook <kees@...ntu.com>
To: oss-security@...ts.openwall.com
Subject: Re: Linux kernel proactive security hardening

On Mon, Nov 08, 2010 at 06:07:38AM +0300, Solar Designer wrote:
> On a more relevant issue (to us), any ideas on dealing with kernel stack
> infoleaks in a general manner (not just plugging the bugs one by one)?
> I guess it could be addressed in gcc (an option to wipe stack frames) or
> in the kernel (wipe even more of the stack, beyond the stack pointer, on
> syscall entry).  Unfortunately, either has likely measurable performance
> impact.  (BTW, has some of this been implemented somewhere already?)
> Any other ideas?

I haven't seen this, but it seems like a good idea. I'd assume the most
efficient solution would be a compiler modification that did the stack
clearing after raising the stack pointer from a call. I can't imagine it
would be too expensive since that area of the stack should already be in
CPU memory cache.

> In the absence of cheap-enough general solution/workaround in the
> kernel, I'm afraid we'll need to resort to improving and using automated
> tools to detect bugs of this nature - which is apparently what you and
> Vasiliy were doing lately?  What tools did you use?

Dan has been using grep. :) I and Vasiliy have been using coccinelle. I am
planning on writing up my adventures soon; I have a giant ruleset for
matching "good" uses of copy_from_user() so that I can manually audit the
less-obviously-correct uses.

-Kees

-- 
Kees Cook
Ubuntu Security Team

Powered by blists - more mailing lists

Please check out the Open Source Software Security Wiki, which is counterpart to this mailing list.

Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.