GccSsp

Differences between revisions 7 and 8
Revision 7 as of 2006-06-15 17:01:51
Size: 1350
Editor: 195
Comment: update status
Revision 8 as of 2006-06-19 17:50:44
Size: 2824
Editor: ALagny-109-1-2-23
Comment: update from today's BoF
Deletions are marked like this. Additions are marked like this.
Line 16: Line 16:
A considerable percentage of arbitrary code execution vulnerabilities result from buffer overflows; about half of them occur due to overflowing a stack variable. SSP provides a technology to stop exploitability of this class of vulnerabilities by (1) reordering stack variables and (2) adding a 'canary' (a random number) to the bottom of the stack, which is checked when the function is returned, so that attempts to overwrite the return pointer are detected and stopped.

SSP itself has been around for some years and thus has matured quite a bit, and many distros are using it by default already. Therefore this should not be a major risk, since we are merely catching up with existing technology.

While this does not avoid the necessity of issuing USNs, it provides effective zero-day protection for a subset of vulnerabilities, and since it is now in gcc upstream, it is very cheap for us to enable and support.
Line 24: Line 30:
=== Code ===  * To adequately test this, a separate binary archive will be rebuilt, so that the packages may be tested for various errors before the toolchain is changed to enable SSP in edgy+1
Line 26: Line 32:
=== Data preservation and migration ===  * MatthiasKlose will merge back libssp-dev into gcc, so that we do not have to add it as build dependency to packages.
Line 31: Line 37:

 * elmo: why not enable it by default and then see what breaks?

 * http://danwalsh.livejournal.com/6117.html: state in Fedora

 * TODO: ask Adam about the possibility of an test archive with SSP enabled

 * figure out the best possibility of enabling -fstack-protector by default in gcc-4.1

Summary

gcc 4.1 comes with SSP now, which is a nice technology to mitigate exploitability of many buffer overflows. This greatly enhances security in the time between publication of a vulnerability and the USN.

Edgy is a good opportunity to try it out for some particular packages and provide a parallel test archive with SSP enabled by default, so that we can thoroughly test it. If all goes well, we should enable it by default in edgy+1.

Rationale

A considerable percentage of arbitrary code execution vulnerabilities result from buffer overflows; about half of them occur due to overflowing a stack variable. SSP provides a technology to stop exploitability of this class of vulnerabilities by (1) reordering stack variables and (2) adding a 'canary' (a random number) to the bottom of the stack, which is checked when the function is returned, so that attempts to overwrite the return pointer are detected and stopped.

SSP itself has been around for some years and thus has matured quite a bit, and many distros are using it by default already. Therefore this should not be a major risk, since we are merely catching up with existing technology.

While this does not avoid the necessity of issuing USNs, it provides effective zero-day protection for a subset of vulnerabilities, and since it is now in gcc upstream, it is very cheap for us to enable and support.

Use cases

Scope

Design

Implementation

  • To adequately test this, a separate binary archive will be rebuilt, so that the packages may be tested for various errors before the toolchain is changed to enable SSP in edgy+1
  • MatthiasKlose will merge back libssp-dev into gcc, so that we do not have to add it as build dependency to packages.

Outstanding issues

BoF agenda and discussion

  • elmo: why not enable it by default and then see what breaks?
  • http://danwalsh.livejournal.com/6117.html: state in Fedora

  • TODO: ask Adam about the possibility of an test archive with SSP enabled
  • figure out the best possibility of enabling -fstack-protector by default in gcc-4.1

Field research

The following dapper packages have been tested with SSP enabled (built with gcc-4.1 and -fstack-protector under edgy):

perl

ok

python

ok

apache2

ok

php5

ok

postgresql-8.1

ok on edgy, fail in sid due to linking problem

firefox

ok

mysql-dfsg-5.0

ok

glib2.0

ok

gtk+2.0

ok

glibc

FTBFS with SSP


CategorySpec

GccSsp (last edited 2008-08-06 16:19:12 by localhost)