GccSsp
|
Size: 2824
Comment: update from today's BoF
|
Size: 2953
Comment: drafting
|
| Deletions are marked like this. | Additions are marked like this. |
| Line 6: | Line 6: |
| * '''Packages affected''': many | * '''Packages affected''': `gcc-4.1`, all |
| Line 12: | Line 12: |
| 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. |
|
| Line 16: | Line 14: |
| 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. | A considerable percentage of arbitrary code execution vulnerabilities result from buffer overflows; about half of them occur due to overflowing a stack variable. 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 == * Pitti reads about a stack buffer overflow in Firefox. However, backporting the fix to our current stable release takes a while. Users of our stable release can live for a while with Firefox crashing when visiting a malicious web site, but they do not want to be subject to arbitrary code execution until an USN is published. == Scope == This affects all packages in all components. == Design == 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. |
| Line 20: | Line 30: |
| 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 == |
|
| Line 30: | Line 32: |
| * 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 | RedHat and gentoo are using SSP by default for years, so we do not expect much breakage potential. So we will build packages with SSP enabled right from the start in Edgy, so that we have much time to discover breakage. If it is not trivial to fix a package for SSP, we can disable it by building it with `fno-stack-protector`. |
| Line 32: | Line 34: |
| * 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 == |
=== testing === |
| Line 54: | Line 42: |
| || postgresql-8.1 || ok on edgy, fail in sid due to linking problem || | || postgresql-8.1 || ok || |
| Line 59: | Line 47: |
| || glibc || FTBFS with SSP || | || glibc || a local build automatically uses SSP if it is available; needs testing || || xorg || || Before enabling SSP by default we will ensure that all those packages work flawlessly with SSP. === gcc changes === * Merge back libssp-dev into gcc, so that we do not have to add it as build dependency to packages. * Change `gcc-4.1` to enable `-fstack-protector` by default. |
Launchpad Entry: https://launchpad.net/distros/ubuntu/+spec/gcc-ssp
Created: 2006-06-14 by MartinPitt
Contributors: MartinPitt
Packages affected: gcc-4.1, all
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.
Rationale
A considerable percentage of arbitrary code execution vulnerabilities result from buffer overflows; about half of them occur due to overflowing a stack variable. 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
- Pitti reads about a stack buffer overflow in Firefox. However, backporting the fix to our current stable release takes a while. Users of our stable release can live for a while with Firefox crashing when visiting a malicious web site, but they do not want to be subject to arbitrary code execution until an USN is published.
Scope
This affects all packages in all components.
Design
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.
Implementation
RedHat and gentoo are using SSP by default for years, so we do not expect much breakage potential. So we will build packages with SSP enabled right from the start in Edgy, so that we have much time to discover breakage. If it is not trivial to fix a package for SSP, we can disable it by building it with fno-stack-protector.
testing
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 |
firefox |
ok |
mysql-dfsg-5.0 |
ok |
glib2.0 |
ok |
gtk+2.0 |
ok |
glibc |
a local build automatically uses SSP if it is available; needs testing |
xorg |
|
Before enabling SSP by default we will ensure that all those packages work flawlessly with SSP.
gcc changes
- Merge back libssp-dev into gcc, so that we do not have to add it as build dependency to packages.
Change gcc-4.1 to enable -fstack-protector by default.
GccSsp (last edited 2008-08-06 16:19:12 by localhost)