[kernel-hardening] Format string gcc-plugin?

[kernel-hardening] Format string gcc-plugin?

[Laura Abbott]

Hi,

The recent discussions about %pk led me to start playing around
with writing a gcc plugin (notes about writing a gcc plugin are
forthcoming). My idea was to expand checking of the kernel's additional
formats (%pK, %pR etc.) or possibly even change the format
strings. The big issue is that most of vsprintf.c would end up
in the plugin which would be ugly to maintain. This concept could
be used for some of the problems with kernel pointer leaks
https://kernsec.org/wiki/index.php/Bug_Classes/Kernel_pointer_leak
but I'm interested if anyone else has thoughts or ideas about
how better to do this (or even not to do this).

Thanks,
Laura

Re: [kernel-hardening] Format string gcc-plugin?

[Kees Cook]

On Tue, Feb 14, 2017 at 10:01 AM, Laura Abbott <labbott@redhat.com> wrote:
> Hi,
>
> The recent discussions about %pk led me to start playing around
> with writing a gcc plugin (notes about writing a gcc plugin are
> forthcoming). My idea was to expand checking of the kernel's additional
> formats (%pK, %pR etc.) or possibly even change the format
> strings. The big issue is that most of vsprintf.c would end up
> in the plugin which would be ugly to maintain. This concept could
> be used for some of the problems with kernel pointer leaks
> https://kernsec.org/wiki/index.php/Bug_Classes/Kernel_pointer_leak
> but I'm interested if anyone else has thoughts or ideas about
> how better to do this (or even not to do this).

If we can leverage common code between the plugin and vsprintf.c, it
should be doable. I haven't looked at processing format strings at
all, though I assume the plugin would need to check the
__printf-generated attributes.

In my related notes was a hint that looking at how gcc does it
normally is gcc/c-family/c-format.c:
http://stackoverflow.com/a/16336175

And while not strictly part of format type checking, I talked a bit
about dealing with const strings here:
http://www.openwall.com/lists/kernel-hardening/2016/12/07/16

-Kees

-- 
Kees Cook
Pixel Security

RE: [kernel-hardening] Format string gcc-plugin?

[Roberts, William C]

> -----Original Message-----
> From: keescook@google.com [mailto:keescook@google.com] On Behalf Of Kees
> Cook
> Sent: Tuesday, February 14, 2017 11:08 AM
> To: Laura Abbott <labbott@redhat.com>
> Cc: kernel-hardening@lists.openwall.com
> Subject: Re: [kernel-hardening] Format string gcc-plugin?
> 
> On Tue, Feb 14, 2017 at 10:01 AM, Laura Abbott <labbott@redhat.com> wrote:
> > Hi,
> >
> > The recent discussions about %pk led me to start playing around with
> > writing a gcc plugin (notes about writing a gcc plugin are
> > forthcoming). My idea was to expand checking of the kernel's
> > additional formats (%pK, %pR etc.) or possibly even change the format
> > strings. The big issue is that most of vsprintf.c would end up in the
> > plugin which would be ugly to maintain. This concept could be used for
> > some of the problems with kernel pointer leaks
> > https://kernsec.org/wiki/index.php/Bug_Classes/Kernel_pointer_leak
> > but I'm interested if anyone else has thoughts or ideas about how
> > better to do this (or even not to do this).
> 
> If we can leverage common code between the plugin and vsprintf.c, it should be
> doable. I haven't looked at processing format strings at all, though I assume the
> plugin would need to check the __printf-generated attributes.
> 
> In my related notes was a hint that looking at how gcc does it normally is gcc/c-
> family/c-format.c:
> http://stackoverflow.com/a/16336175
> 
> And while not strictly part of format type checking, I talked a bit about dealing
> with const strings here:
> http://www.openwall.com/lists/kernel-hardening/2016/12/07/16
> 
> -Kees
> 
> --
> Kees Cook
> Pixel Security

gcc would be nice since it's the compiler most often used for building linux kernel (does clang work fully yet?)

Nicolas Iooss was able to use UBSan to find one:

commit 901d805c33fc4c029fc6b2d94ee5fb7d30278045
Author: Nicolas Iooss <nicolas.iooss_linux@m4x.org>
Date:   Tue Aug 2 14:03:10 2016 -0700

    UBSAN: fix typo in format string

[kernel-hardening] Re: Format string gcc-plugin?

[Rasmus Villemoes]

On Tue, Feb 14 2017, Kees Cook <keescook@chromium.org> wrote:

> On Tue, Feb 14, 2017 at 10:01 AM, Laura Abbott <labbott@redhat.com> wrote:
>> Hi,
>>
>> The recent discussions about %pk led me to start playing around
>> with writing a gcc plugin (notes about writing a gcc plugin are
>> forthcoming). My idea was to expand checking of the kernel's additional
>> formats (%pK, %pR etc.) or possibly even change the format
>> strings. The big issue is that most of vsprintf.c would end up
>> in the plugin which would be ugly to maintain. This concept could
>> be used for some of the problems with kernel pointer leaks
>> https://kernsec.org/wiki/index.php/Bug_Classes/Kernel_pointer_leak
>> but I'm interested if anyone else has thoughts or ideas about
>> how better to do this (or even not to do this).
>
> If we can leverage common code between the plugin and vsprintf.c, it
> should be doable. I haven't looked at processing format strings at
> all, though I assume the plugin would need to check the
> __printf-generated attributes.
>

smatch already does type checking of the kernel's %p extensions, plus
some additional sanity checks (e.g. passing a signed char to %02x,
duplicate KERN_* or KERN_* prefixes not at the beginning, 0x%d,
etc.). Maybe Dan Carpenter is the only one actually running it
periodically. I never managed to get sparse to grok the printf
attribute, so it uses a hardcoded list of printf-like functions. It
would be nice to do these checks in a gcc plugin to get wider coverage
and piggyback on the actual printf attributes, and it would probably be
easier to keep up with the endless stream of new %pX stuff that way.

Rasmus

Re: [kernel-hardening] Re: Format string gcc-plugin?

[Vaishali Thakkar]

On Friday 24 February 2017 04:45 AM, Rasmus Villemoes wrote:
> On Tue, Feb 14 2017, Kees Cook <keescook@chromium.org> wrote:
> 
>> On Tue, Feb 14, 2017 at 10:01 AM, Laura Abbott <labbott@redhat.com> wrote:
>>> Hi,
>>>
>>> The recent discussions about %pk led me to start playing around
>>> with writing a gcc plugin (notes about writing a gcc plugin are
>>> forthcoming). My idea was to expand checking of the kernel's additional
>>> formats (%pK, %pR etc.) or possibly even change the format
>>> strings. The big issue is that most of vsprintf.c would end up
>>> in the plugin which would be ugly to maintain. This concept could
>>> be used for some of the problems with kernel pointer leaks
>>> https://kernsec.org/wiki/index.php/Bug_Classes/Kernel_pointer_leak
>>> but I'm interested if anyone else has thoughts or ideas about
>>> how better to do this (or even not to do this).
>>
>> If we can leverage common code between the plugin and vsprintf.c, it
>> should be doable. I haven't looked at processing format strings at
>> all, though I assume the plugin would need to check the
>> __printf-generated attributes.
>>
> 
> smatch already does type checking of the kernel's %p extensions, plus
> some additional sanity checks (e.g. passing a signed char to %02x,
> duplicate KERN_* or KERN_* prefixes not at the beginning, 0x%d,
> etc.). Maybe Dan Carpenter is the only one actually running it
> periodically. I never managed to get sparse to grok the printf
> attribute, so it uses a hardcoded list of printf-like functions. It
> would be nice to do these checks in a gcc plugin to get wider coverage
> and piggyback on the actual printf attributes, and it would probably be
> easier to keep up with the endless stream of new %pX stuff that way.

Hi all,

I was recently looking at gcc's -Wformat-security and realized that 
there is a TODO point on KSPP's wiki page regarding fixing it for const
strings.

I was wondering that may be we can also try Coccinelle for the type 
checking of %pX extensions? Is there any work done or is someone working 
on this after this discussion?

I'm not sure what is a preferable way over here [GCC plugin or 
Coccinelle scripts] but if noone is working on this then I would like to 
give it a try. Any comments on the same are welcome.

Thanks!

> Rasmus
> 

Re: [kernel-hardening] Re: Format string gcc-plugin?

[Kees Cook]

On Mon, Aug 7, 2017 at 3:06 PM, Vaishali Thakkar
<vaishali.thakkar@oracle.com> wrote:
> I was recently looking at gcc's -Wformat-security and realized that there is
> a TODO point on KSPP's wiki page regarding fixing it for const
> strings.
>
> I was wondering that may be we can also try Coccinelle for the type checking
> of %pX extensions? Is there any work done or is someone working on this
> after this discussion?
>
> I'm not sure what is a preferable way over here [GCC plugin or Coccinelle
> scripts] but if noone is working on this then I would like to give it a try.
> Any comments on the same are welcome.

I would prefer a gcc plugin just because that could be enabled for the
regular build (where as a Coccinelle check is a separate build type).
Also I think a gcc plugin would allow for better control of the
checks, since it will actually be in the middle of constructing the
actual instructions and variables, etc. Coccinelle has to guess
sometimes.

-Kees

-- 
Kees Cook
Pixel Security