Hardened Debian patches for GCC 3.3 and 3.4 (security related enhancements)

[Lorenzo Hernández García-Hierro (a.k.a. trulux)]

Hi,

As i've talked with doko about them , here is the summary of the patches that
i've made with other developers from the Hardened Debian project.

First one is the updated and re-packaged sources for IBM's Stack Smashing
Protector / ProPolice, which replaces the default protector patches coming
inside the default Debian Sarge gcc sources (gcc-3.3).Patches and UUEncoded
sources attached.
(Check for more revisions and information
http://www.trl.ibm.com/projects/security/ssp/)

Second one was made by some gentoo developers (tigger and lv) and adds support
for SPECS file declaration by using an environment variable (GCC_SPECS), the
original patch can be found at http://dev.gentoo.org/~lv/gcc-spec-env.patch and
the dpatch is attached.

Third one does not work properly on gcc-3.3, but works without problems on later
versions of GCC.
It enables the use of the libssp by tweaking the compilation of protector stuff
on libgcc, defining it as provided by libc (-D_LIBC_PROVIDES_SSP_),libssp is an
implementation of SSP/ProPolice as a shared library.
A pre-release of the 0.2 revision of libssp can be found at
http://lorenzo.debian-hardened.org/debhard/libssp-0.2.tar.gz.

On gcc-3.3 the gcc/Makefile.in must be edited by hand and add after the
LIBGCC2_CFLAGS definition a simple LIBGCC2_CFLAGS += -D_LIBC_PROVIDES_SPP_ to
avoid cnflicts with other crappy patches.

The results are these:

lorenzo@dunruin:~/LIBSSP/libssp-0.2$ ls /lib | grep ssp && ls /usr/lib/ | grep ssp
libssp.so.0
libssp.so.0.2
libssp.a
libssp.so
lorenzo@dunruin:~/LIBSSP/libssp-0.2$

lorenzo@dunruin:~/LIBSSP/libssp-0.2$ gcc -fstack-protector -lssp vuln-stack.c
vuln-stack.c: En la función `main':
vuln-stack.c:9: aviso: asignación se crea un entero desde un puntero sin una
conversión
lorenzo@dunruin:~/LIBSSP/libssp-0.2$ ./a.out
Appending [22] to a buffer thats [15] bytes long with a max buffer size of [16]
a.out: stack smashing attack in function main()
----
main=0x80000a51 __guard_setup=0x4001daf0 __guard=0xfce4e13d
ppid=10622 pid=13512 uid=1000 euid=1000 gid=1000 egid=1000
----
Abortado
lorenzo@dunruin:~/LIBSSP/libssp-0.2$

Sorry of the localized messages ;-)

Any other documentation can be find at http://wiki.debian-hardened.org

Cheers,
Lorenzo.

http://www.debian-hardened.org: http://www.debian-hardened.org

[Lorenzo Hernández García-Hierro (a.k.a. trulux) (lorenzo-debian-hardened)]

Created an attachment (id=874)
Patch for GCC 3.{3,4} to recognize the GCC_SPECS env var for specs file
declaration.

Added the GCC_SPECS related (d)patch.

[Lorenzo Hernández García-Hierro (a.k.a. trulux) (lorenzo-debian-hardened)]

Created an attachment (id=875)
libssp patch for GCC.NOT for gcc-3.3.

This patch wouldn't work at gcc-3.3, should edit gcc/Makefile.in manually as i
said before.

[Lorenzo Hernández García-Hierro (a.k.a. trulux) (lorenzo-debian-hardened)]

Created an attachment (id=876)
GCC 3.3 Position Independent Executables support patch.

Adds support for Position Independent Executables (formerly known as "PIE").
More information at bluefoxicy's page:
http://d-sbd.alioth.debian.org/www/?page=pax_pie

Its main intenttion is to take benefit of the PaX ASLR capabilities.
(Address Space Layout Randomization).

[Lorenzo Hernández García-Hierro (a.k.a. trulux) (lorenzo-debian-hardened)]

Created an attachment (id=877)
UUEncoded source of the PIE dpatch.

[Lorenzo Hernández García-Hierro (a.k.a. trulux) (lorenzo-debian-hardened)]

Created an attachment (id=878)
SSP/ProPolice dpatch for GCC. (updated)

(d) patch for Stack Smashing Protector / ProPolice stuff.
Must be applied before the libssp dpatch if its used.(it's not on gcc-3.3 when
Makefile.in has been edited by hand).

[Lorenzo Hernández García-Hierro (a.k.a. trulux) (lorenzo-debian-hardened)]

Created an attachment (id=879)
SSP/ProPolice dpatch UUEncoded sourcesfor GCC. (updated)

[Lorenzo Hernández García-Hierro (a.k.a. trulux) (lorenzo-debian-hardened)]

The patches should be applied in this order:
1.- protector
2.- pie
3.- gcc-env-specs
4.- libssp (if not gcc-3.3)

Cheers.

[Lorenzo Hernández García-Hierro (a.k.a. trulux) (lorenzo-debian-hardened)]

New PIE patches available, better support.
ASAP i will upload them and see how well they work.

Cheers.

[Lorenzo Hernández García-Hierro (a.k.a. trulux) (lorenzo-debian-hardened)]

Created an attachment (id=914)
libssp patch 0.2 for GCC 3.4 with updated support

SSP/ProPolice library patch (libssp) updated patch for GCC 3.4
Tested on hoary gcc-3.4 sources.

GCC packages for hoary (3.4) updated and uploaded to:
http://d-sbd.alioth.debian.org/apt/hoary/

Repository line:
deb http://d-sbd.alioth.debian.org/apt/hoary/ ./

[Lorenzo Hernández García-Hierro (a.k.a. trulux) (lorenzo-debian-hardened)]

Created an attachment (id=915)
GCC 3.4.3 SSP/ProPolice updated & paths-fixed patch

[Matthias Klose (doko)]

Lorenzo,

my understanding was, that you agreed with Martin to build separate packages,
which can be installed in parallel with gcc-3.4 and used in an explicit way,
i.e. calling gcc-ssp-3.4.

[Lorenzo Hernández García-Hierro (a.k.a. trulux) (lorenzo-debian-hardened)]

Hi Matthias,

The point is that we wouldn't need to rename the GCC packages anymore.
Alexander Gabert and me did a gcc wrapper implemented in C that works as follows
(it's based on Gentoo's gcc-config and also on an old wrapper i wrote as a bash
script):

# export GCC_AUTOPIE_DISABLE=1
# export GCC_AUTOSSP_DISABLE=1
# export GCC_AUTOSSP_ALL_DISABLE=1
gcc -D__GCC_REALGCC_PATH__=\"/usr/bin/gcc-3.4\" -g -ggdb -O2 -Wall -o ./wrapper
wrapper-1.4.2-PIE-SSP-suppression.c

With that we will have a non-invassive GCC with all the hardening features non
enabled by default.
We can use a simple script to dinamically compile it as we want to enable XYZ or
FOO feature depending on our needs.
No overhead when using it, and also no unwanted developer-side effects.

BTW, Martin, the pkgs are OK, it was just a mistake i forgot that gcc was a
symlink to gcc-3.3 and not gcc-3.4 (which is OK and you can upload the packages
whenever you want).

[John Moser (nigelenki)]

"Alexander Gabert and me did a gcc wrapper implemented in C that works as
follows (it's based on Gentoo's gcc-config and also on an old wrapper i wrote as
a bash script):"

Why a wrapper? You have the GCC_SPECS patch. Once they're stable you could
just match a proper gcc specs file up. If you want to initially do a vanilla
specs by default that's fine; if you want the Debian tools to change GCC_SPECS
and leave a vanilla one for default, that's fine; if you want to use GCC_SPECS
to test out new specs, then move them into default, that's fine; there's no need
for two gcc packages just for the specs file mods.

As for the other patches, like ProPolice, those should be tested before release;
however, I seriously recommend deciding whether you want to officially support
ProPolice or not. In Gentoo, gcc *always* has ProPolice patched in. This
causes variables to be arranged below buffers (no overhead at runtime), and
other things; but without -fstack-protector*, there's no __guard value usage or
checking, and no linking with symbols specific to SSP. This is well tested and
seems sane.

I believe you should test it out first, yes, make sure it's release quality; but
it just makes you look like you don't know what you're doing if you have a
non-ssp and an ssp gcc. It's like you're not sure if you want to support it or
not. If your distribution is going to run on SSP, you should support an SSP
compiler. It's perfectly sane to use a vanilla specs file by default though, so
that binaries built on Ubuntu don't automatically get SSP and wind up
incompatible with other Linux distributions; the Debian tools can be made to
change GCC_SPECS to use a hardened one during the building of Ubuntu.

Ah well, I haven't done any of the work, so maybe I'm wrong.

[Lorenzo Hernández García-Hierro (a.k.a. trulux) (lorenzo-debian-hardened)]

(In reply to comment #13)
> "Alexander Gabert and me did a gcc wrapper implemented in C that works as
> follows (it's based on Gentoo's gcc-config and also on an old wrapper i wrote as
> a bash script):"
>
> Why a wrapper? You have the GCC_SPECS patch. Once they're stable you could
> just match a proper gcc specs file up. If you want to initially do a vanilla
> specs by default that's fine; if you want the Debian tools to change GCC_SPECS
> and leave a vanilla one for default, that's fine; if you want to use GCC_SPECS
> to test out new specs, then move them into default, that's fine; there's no need
> for two gcc packages just for the specs file mods.

Let me tell you, first, we use libssp, not SSP inside Glibc nor inside libgcc
.I don't know if you get the point of what that means, but if you don't you
should know that using GCC_SPECS variable
is nonsense because we can do it in a non-preformance loss way, rather than
using crap bash scripts and such things.
Also, we *don't* need to write our own specs file, within the wrapper this is
handled smartly, so. nothing stupid around making noisy errors with messed up specs.
BTW, i'm not a specs file hacker, but instead i can put some fu in the design
and deployment part of it, and that's because i decided to use a wrapper instead
a specs file.It's KISS, it's smart and there's no real performance loss (using
special spoecs for everything will end in a messing up without sense).

> As for the other patches, like ProPolice, those should be tested before release;
> however, I seriously recommend deciding whether you want to officially support
> ProPolice or not. In Gentoo, gcc *always* has ProPolice patched in. This
> causes variables to be arranged below buffers (no overhead at runtime), and
> other things; but without -fstack-protector*, there's no __guard value usage or
> checking, and no linking with symbols specific to SSP. This is well tested and
> seems sane.
>

Who said it's not?
SSP shouldn't be enabled by default, that's because the wrapper is the best
solution, we handle things without recompiling the whole stuff.John, we are
thinking in future terms, now we have a small users pool, but in some months we
will get more & more (tm) users that would desire a right design and
implementation, not a crappy thing that would end in the lost of all the efforts.

Also Gentoo gets SSP symbols inside the glibc, which is not a good idea in *our*
opinion.

> I believe you should test it out first, yes, make sure it's release quality; but
> it just makes you look like you don't know what you're doing if you have a
> non-ssp and an ssp gcc. It's like you're not sure if you want to support it or
> not. If your distribution is going to run on SSP, you should support an SSP
> compiler. It's perfectly sane to use a vanilla specs file by default though, so
> that binaries built on Ubuntu don't automatically get SSP and wind up
> incompatible with other Linux distributions; the Debian tools can be made to
> change GCC_SPECS to use a hardened one during the building of Ubuntu.

John, you are saying things i didn't, first, we would use SSP inside GCC, but
not enabled by default, right?, here comes libss...

[John Moser (nigelenki)]

> using GCC_SPECS variable is nonsense because we can do
> it in a non-preformance loss way, rather than using crap
> bash scripts and such things.

Some build systems don't honor CFLAGS.

Setting GCC_SPECS and then exporting it gets it inherited down through the
environment, which means no performance hit.

> SSP shouldn't be enabled by default, that's because the
> wrapper is the best solution, we handle things without
> recompiling the whole stuff.

I mean build gcc with ssp patched in, not enable SSP protections by default.
Using -fstack-protector causes extra checks to be built in to the outputted
code, and causes it to be linked against libssp.

Based on my regression tests, patching gcc with ProPolice builds a gcc which
makes a few modifications to the output that produce no extra checking or
performance hit, and don't use libssp symbols or anything (and thus don't need
to link with libssp); but which are generally good. This includes simple things
like altering local variable declaration order to make sure that overflows don't
clobber local variables.

int foo() {
  char *vuln_pointer; //vulnerable
  char a[10]; // overflow will damage vuln_pointer
  strcpy(a, "1234567890vuln"); // damage vuln_ptr;
  return 1;
}

// or with SSP-patched gcc
int foo() {
  char a[10]; // overflow will not damage vuln_pointer
  char *vuln_pointer; // not vulnerable
  strcpy(a, "1234567890vuln"); // can't damage vuln_ptr;
  return 1;
}

Adding -fstack-protector will change the function to have extra ssp checking.

// or with SSP-patched gcc with -fstack-protector
int foo() {
  int guard = __guard; // NEW from -fstack-protector
  char a[10]; // overflow will not damage vuln_pointer
  char *vuln_pointer; // not vulnerable
  strcpy(a, "1234567890vuln"); // can't damage vuln_ptr;
  if (guard != __guard) // NEW check from -fstack-protector
    stack_smash_handler();
  return 1;
}

Matthias suggested using two separate gcc packages; I see no need for this. I
believe it is safe and sane to package an SSP patched gcc only. I'm only
concerned here because I don't want to see extra cruft; why package, for
example, a 16bpp wallpaper and a 24bpp wallpaper when the 24bpp wallpaper will
be translated anyway? Similarly, why package a ssp and non-ssp patched gcc when
packages built without -fstack-protector using the ssp-patched gcc will run on
redhat, mandrake, suse, and slack? As long as there's no compatibility issue,
there shouldn't be a problem.

> Also Gentoo gets SSP symbols inside the glibc, which is
> not a good idea in *our* opinion.

Trivial. You use libssp. It doesn't matter, the concept is the same.

> John, you are saying things i didn't, first, we would use
> SSP inside GCC, but not enabled by default, right?, here
> comes libssp, and also the wrapper to manage it smartly.
>
> GCC_SPECS is now crap stuff, deprecated in the terms we
> are going to handle, and just provided for special cases.

Why not use a wrapper that just controls the GCC_SPECS environment variable?

How are you going to deploy your wrappers? If you use things like $(CC) or
$(CFLAGS), some build environments will clobber or ignore these. If you export
a variable that build envir...

[Matt Zimmerman (mdz)]

When this was discussed in Mataro, it was pointed out that even with the feature
disabled, this patches touches common code (and thus could affect the behaviour
of SSP-disabled gcc). This was one of the problems with it.

I haven't looked at the patch myself, but perhaps someone who has could comment.

[Lorenzo Hernández García-Hierro (a.k.a. trulux) (lorenzo-debian-hardened)]

(In reply to comment #16)
> When this was discussed in Mataro, it was pointed out that even with the feature
> disabled, this patches touches common code (and thus could affect the behaviour
> of SSP-disabled gcc). This was one of the problems with it.
>
> I haven't looked at the patch myself, but perhaps someone who has could comment.

When SSP gets compiled inside libgcc, it grabs there it symbols and adds
problems with specific environments.
John can make some points on this.

Also, as a reply of his last message, the wrappers DON'T use CFLAGS and so on,
that's crap.
Instead of using environment variables for flags, it grabs in a fine grained
manner, as you said referring to SPECS file (which also means start touching an
important part of gcc), the flags depending on what's being compiled.

The wrappers are two, one for gcc and another one for ld.

The libssp now needs a few fixing as Alexander discovered some unexpected
effects (which are not major problems), and he is working for fix them.

> Trivial. You use libssp. It doesn't matter, the concept is the same.

The main reason for using libssp is to make a less agressive implementation of
the SSP routines.
The concept is not the same, but it provides the same (good) thing ;-)

We are not using GCC_SPECS because it's a lack of time and a lack of usability,
it's good for those who want a fast interface to specs modification on compile
time, and what we want is not to change specs, is to change the compile and
linking flags without interferring with the whole work.

Cheers,
Lorenzo.

[Matthias Klose (doko)]

it's not just Lorenzo's patch itself, but an already existing patch currently in
the package, which is not yet applied, and has to be enabled.

[Matthias Klose (doko)]

FYI, the patches are included (not applied) in the current gcc-3.3 and gcc-3.4
packages.

[John Moser (nigelenki)]

(In reply to comment #16)
> When this was discussed in Mataro, it was pointed out that even with the feature
> disabled, this patches touches common code (and thus could affect the behaviour
> of SSP-disabled gcc). This was one of the problems with it.
>

With SSP disabled, the declaration order of local variables is reordered to place
local arrays higher in the stack frame than everything else. I believe the order
is something akin to:

char[]
other_arrays[]
structs
basic_types_like_int_and_float_and_char
pointers

so for example

void foo() {
  int a;
  void *b;
  int c;
  char d[10];
}

would become

void foo() {
  char d[10];
  int a;
  int c;
  void *b;
}

This shouldn't affect anything; though if d[] were overflowed, you wouldn't risk
arbitrary reads or writes using the new value of b.

In general this should be a "good idea" regardless of whether you use
-fstack-protector or not. No performance hit, nothing is added, nothing removed.

> I haven't looked at the patch myself, but perhaps someone who has could comment.

[Lorenzo Hernández García-Hierro (a.k.a. trulux) (lorenzo-debian-hardened)]

Changed priority and target milestone.

As discussed in #ubuntu-hardened and #ubuntu-devel, at least gcc-3.4 packages
should get the SSP patches enabled (but SSP won't be enabled by default, we will
need to use the forthcoming gcc-3.4-hardened packages (which will depend on
gcc-3.4 and libssp1) providing both gcc and ld wrappers for SSP and PIE flags
automatic enabling (in a near future we would use just a specs-base system using
profiles much like Gentoo does), using the specs patch already included
(GCC_SPECS env. variable availability).

Time to rock the house, Martin ;)

[Matthias Klose (doko)]

closing the report as wontfix. ssp support will be available in gcc-4.1.