[hardening-discuss] Using hardening-wrapper but lintian warning still present

[Kees Cook]

Hi José,

On Wed, Jun 20, 2012 at 12:21:15PM +0200, José Luis Segura Lucas wrote:
> I'm intending to package a software for Debian. I have a Debian package
> with some lintian warning about hardening, but I removed most of them
> using hardening-wrapper and the env DEB_BUILD_HARDENING=1 in my
> debian/rules.

If you're using debhelper compat level 9, you don't have to worry about
including hardening-wrapper and using DEB_BUILD_HARDENING=1. You'll get
the defaults automatically through debhelper. This is the preferred way
to get build flags now.

> I only have one lintian warning now: hardening-no-fortify-functions
> 
> I see that the -D_FORTIFY_SOURCE=2 is included in each compiler
> execution. This is the output of hardening-check:
> 
>     $ hardening-check --verbose /usr/bin/grive
>     /usr/bin/grive:
>      Position Independent Executable: yes
>      Stack protected: yes
>      Fortify Source functions: no, only unprotected functions found!
>         unprotected: memmove
>         unprotected: read
>         unprotected: memcpy
>      Read-only relocations: yes
>      Immediate binding: yes
> 
> I asked on debian-devel and they told me that I can add an override if
> only memmove ormemcpy is shown, but I have an unprotected read too.
> 
> How can I avoid this warning? It is my last problem after doing the RFS...

It is possible that the read() was checked at compile-time to be
safe which is why it was not linked with the protected version
("__read_chk"). For example, this will always be safe:

    char buf[100];
    ...
    read(fd, buf, 50);

In this case, the compiler can see that the read() can never overflow
the buf (50 is less than 100), so there is no reason to use the protected
function.

If you're building with -O1 (or higher) and -D_FORTIFY_SOURCE=2, the
compiler is always always going to be doing the right thing. :)

If you really want to, you can test that this is the case by finding the
uses of read() and using a volatile global variable to replace the length
argument. (Don't leave the code like this, since it's not a useful change,
but it can be used to make sure the compiler is doing the right thing.)

  volatile size_t read_length;
  ...
  char buf[100];
  ...
  read_length = 50;
  read(fd, buf, read_length);

If making that change causes hardening-check to see the __read_chk call,
then the compiler is being smart and noticed that it doesn't need to do
extra work at run time to verify the arguments, and you're clear to put
in a lintian override.

-Kees

-- 
Kees Cook                                            @outflux.net