Re: Linux kernel proactive security hardening

[Vasiliy Kulikov <segooon () gmail com>]

Solar,

On Mon, Nov 08, 2010 at 06:07 +0300, Solar Designer wrote:
> 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?

At first I was using simple "grep copy_to_user" and manually checked all
calls to copy_to_user().  Then I used coccinelle [1] to search this
pattern: struct allocated on the stack, not prepared with neither
copy_from_user() nor memset(), is copied with copy_to_user().  Both
result are manually checked.  The latter doesn't find all the cases of
leak, see e.g. [2].  The caller copies array, not struct.  Maybe my
cocci script should be added with s/struct/array/ too.  Search with
pahole or similar sucks as many leaks are not only padding bytes leaks,
but trivial uninitialized fields or using strlcpy() (instead of strncpy()).


Also note that even if this "pattern search" process can be fully automated,
we might have another more difficult to discover "pattern": struct is
allocated with kmalloc(), is not fully initialized and then is copied to
userspace, somewhere far from kmalloc() (not in this module or even not
in this driver layer).  Maybe this can be still automated with
coccinelle, e.g. search for all copy_to_user() that copies _not local_
struct/array and then check all dynamic allocation of this struct type
(hard to check _all_ the cases :( ).

But again, it also can be complicated by "virtual methods" those are called
through pointers to functions those use different types of struct: the
caller uses "struct A", the callee uses "struct B" that has struct A as
the first field.  (Yes, I know that the right code should use
container_of() macro.)


[1] http://coccinelle.lip6.fr/

[2] http://www.openwall.com/lists/oss-security/2010/11/02/7


Thanks,

-- 
Vasiliy