Lightweight buffer overflow handling in 10.0 / Factory
(This is a report of a pre-10.0 article from internal list).
Hi folks,
The gcc 4 introduction brings fortunately some enhancements in
regards to better checks for security problems.
One of them is light weight buffer overflow checking during compile
and runtime.
Technical Details:
==================
If the C compiler define -D_FORTIFY_SOURCE=x is specified
(x can be 1 or 2 currently), special versions of "memcpy", "strcpy",
"sprintf", "gets", and so on are defined and compiled differently,
so that code like this:
char buf[10];
strcpy(buf,"Hello world!");
now generates warnings like:
xx.c:5: warning: call to __builtin___strcpy_chk will always overflow destination buffer
and runtime errors like:
./xx
*** buffer overflow detected ***
Those errors of course need to be fixed.
This checking method can only detect overflows if the destination buffer
size is known at compile time.
The performance impact of this method is low.
Current Status:
===============
Introduced with 10.0 snapshot 2 we are now using "-D_FORTIFY_SOURCE=2" as
default in the RPM_OPT_FLAGS.
We have fixed all problems we found in the buildsystem already.
Packager TODOs:
===============
However, this requires the following from you:
* Make sure that strcpy, memcpy and friends are not implicitly defined.
If you see this warning:
"implicit declaration of function #strcpy#"
it will not detect those simple buffer overflows.
To fix such cases, include the standard header:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Marcus Meissner wrote:
(This is a report of a pre-10.0 article from internal list).
Hi folks, The gcc 4 introduction brings fortunately some enhancements in regards to better checks for security problems. One of them is light weight buffer overflow checking during compile and runtime.
...
Introduced with 10.0 snapshot 2 we are now using "-D_FORTIFY_SOURCE=2" as default in the RPM_OPT_FLAGS.
Yes, that GCC feature already has been helpful in a few cases (to sort out e.g. double memory deallocation).
We have fixed all problems we found in the buildsystem already.
?
Packager TODOs: =============== However, this requires the following from you: * Make sure that strcpy, memcpy and friends are not implicitly defined. If you see this warning: "implicit declaration of function #strcpy#" it will not detect those simple buffer overflows. To fix such cases, include the standard header:
(for *printf warnings, )
Thanks for that information, I'll try to fix them all from now on. Sometimes I do, sometimes I don't, depends on the number (and the time I have ;)). I'll do my best to fix them all from now on. Hopefully upstream will pick up the patches. Could it be possible to have a "packager corner" on the opensuse wiki and post stuff like that over there ? Would be helpful when we submit patches to upstream, we can give them a link to your explanation, which should give some weight to the patches ;)
* Make sure your package uses RPM_OPT_FLAGS for compiling C and C++ code. There is still a number of package that does not do this. I have run a heuristics (grep ;) over all our autobuild logfiles to find such offenders.
Yeah, indeed, still happens sometimes. A very stupid trick, but works pretty well: when I compile the sources for the first time (to gather information to write the spec file), I pass -DXXXXXXXXXXXXXXXXXXXXXXXXXXXX (or something like that) to CFLAGS/CXXFLAGS. It's very easy to see whether it's used when the source is compiling ;)) (and it doesn't have any side effects).
The logfile seperated by maintainer is in: <internalpath> the full warnings logfile is at <internalpath>
What is <internalpath> ? *grin* ;)
NOTE! There might be reasons you can't use RPM_OPT_FLAGS, or that only matches for package internal buildtools where found. These are cases where the heuristic failed. This is no official endorsement of RPM_OPT_FLAGS (yet).
What do you mean with "no official endorsement of RPM_OPT_FLAGS yet" ?
cheers
- --
-o) Pascal Bleser http://linux01.gwdg.de/~pbleser/
/\\
Am Freitag, 13. Januar 2006 00:06 schrieb Pascal Bleser:
Marcus Meissner wrote:
Introduced with 10.0 snapshot 2 we are now using "-D_FORTIFY_SOURCE=2" as default in the RPM_OPT_FLAGS.
Yes, that GCC feature already has been helpful in a few cases (to sort out e.g. double memory deallocation).
We have fixed all problems we found in the buildsystem already.
?
means all packages in factory got fixed.
Packager TODOs: =============== However, this requires the following from you: * Make sure that strcpy, memcpy and friends are not implicitly defined. If you see this warning: "implicit declaration of function #strcpy#" it will not detect those simple buffer overflows. To fix such cases, include the standard header:
(for *printf warnings, ) Thanks for that information, I'll try to fix them all from now on. Sometimes I do, sometimes I don't, depends on the number (and the time I have ;)). I'll do my best to fix them all from now on. Hopefully upstream will pick up the patches.
Could it be possible to have a "packager corner" on the opensuse wiki and post stuff like that over there ? Would be helpful when we submit patches to upstream, we can give them a link to your explanation, which should give some weight to the patches ;)
There is already the package howto, this could maybe added there.
The logfile seperated by maintainer is in: <internalpath> the full warnings logfile is at <internalpath>
What is <internalpath> ? *grin* ;)
because Marcus is the security hero ;) bye adrian -- Adrian Schroeter SUSE Linux Products GmbH, Maxfeldstr. 5, 90409 Nuernberg, Germany email: adrian@suse.de
Adrian Schröter píše v Pá 13. 01. 2006 v 10:15 +0100:
Am Freitag, 13. Januar 2006 00:06 schrieb Pascal Bleser:
Marcus Meissner wrote:
Introduced with 10.0 snapshot 2 we are now using "-D_FORTIFY_SOURCE=2" as default in the RPM_OPT_FLAGS.
Yes, that GCC feature already has been helpful in a few cases
And some upstream maintainers were happy with locating of a "random" variable changes they were not able to debug.
Could it be possible to have a "packager corner" on the opensuse wiki and post stuff like that over there ? Would be helpful when we submit patches to upstream, we can give them a link to your explanation, which should give some weight to the patches ;)
There is already the package howto, this could maybe added there.
But packagers corner wiki is a very good idea. Not for things, which should be in packager howto, but for collecting of examples of actually fixed, problems, cool tricks etc. It should look like "Frequently Fixed Problems". If one fixes a problem and thinks, that it can affect more packages, it would be nice to add the experience to the packagers corner. We discussed exactly the same idea in our packagers meeting few weeks ago. -- Best Regards / S pozdravem, Stanislav Brabec software developer --------------------------------------------------------------------- SuSE CR, s. r. o. e-mail: sbrabec@suse.cz Drahobejlova 27 tel: +420 296 542 382 190 00 Praha 9 fax: +420 296 542 374 Czech Republic http://www.suse.cz/
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Stanislav Brabec wrote:
Adrian Schröter píše v Pá 13. 01. 2006 v 10:15 +0100:
Am Freitag, 13. Januar 2006 00:06 schrieb Pascal Bleser:
Marcus Meissner wrote:
Introduced with 10.0 snapshot 2 we are now using "-D_FORTIFY_SOURCE=2" as default in the RPM_OPT_FLAGS. Yes, that GCC feature already has been helpful in a few cases
And some upstream maintainers were happy with locating of a "random" variable changes they were not able to debug.
Seems valgrind is not well-known enough ;)
Could it be possible to have a "packager corner" on the opensuse wiki and post stuff like that over there ? Would be helpful when we submit patches to upstream, we can give them a link to your explanation, which should give some weight to the patches ;) There is already the package howto, this could maybe added there.
But packagers corner wiki is a very good idea. Not for things, which should be in packager howto, but for collecting of examples of actually fixed, problems, cool tricks etc.
Exactly. And things in the wiki could be moved into the SUSE Packaging Conventions if appropriate and discussed enough.
It should look like "Frequently Fixed Problems". If one fixes a problem and thinks, that it can affect more packages, it would be nice to add the experience to the packagers corner. We discussed exactly the same idea in our packagers meeting few weeks ago.
Ok.
Any consciencus on this ? Objections ? +1 votes ? ;)
- --
-o) Pascal Bleser http://linux01.gwdg.de/~pbleser/
/\\
Thanks for that information, I'll try to fix them all from now on. Sometimes I do, sometimes I don't, depends on the number (and the time I have ;)). I'll do my best to fix them all from now on. Hopefully upstream will pick up the patches.
Could it be possible to have a "packager corner" on the opensuse wiki and post stuff like that over there ? Would be helpful when we submit patches to upstream, we can give them a link to your explanation, which should give some weight to the patches ;)
This should be in the package howto ... not sure if it is there.
* Make sure your package uses RPM_OPT_FLAGS for compiling C and C++ code. There is still a number of package that does not do this. I have run a heuristics (grep ;) over all our autobuild logfiles to find such offenders.
Yeah, indeed, still happens sometimes. A very stupid trick, but works pretty well: when I compile the sources for the first time (to gather information to write the spec file), I pass -DXXXXXXXXXXXXXXXXXXXXXXXXXXXX (or something like that) to CFLAGS/CXXFLAGS. It's very easy to see whether it's used when the source is compiling ;)) (and it doesn't have any side effects).
I have a similar check included in our checkscripts.
NOTE! There might be reasons you can't use RPM_OPT_FLAGS, or that only matches for package internal buildtools where found. These are cases where the heuristic failed. This is no official endorsement of RPM_OPT_FLAGS (yet).
What do you mean with "no official endorsement of RPM_OPT_FLAGS yet" ?
We can make our buildsystem fail the packagebuild on certain conditions. One of them could be "not using RPM_OPT_FLAGS". Unfortunately there are still too many of those packages that do not use them. Note that this mail was sent to our internal packagers and was meant for them. It is only for your information for external packagers ;) Ciao, Marcus
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Marcus Meissner wrote:
Thanks for that information, I'll try to fix them all from now on. Sometimes I do, sometimes I don't, depends on the number (and the time I have ;)). I'll do my best to fix them all from now on. Hopefully upstream will pick up the patches.
Could it be possible to have a "packager corner" on the opensuse wiki and post stuff like that over there ? Would be helpful when we submit patches to upstream, we can give them a link to your explanation, which should give some weight to the patches ;)
This should be in the package howto ... not sure if it is there.
Ok, would also be a good place for that information. Nevertheless a part of the wiki for us packagers would be much appreciated. We could start something small (templates, tips/tricks, links, examples) and maybe it will evolve in a howto in a few months' time.
* Make sure your package uses RPM_OPT_FLAGS for compiling C and C++ code. There is still a number of package that does not do this. I have run a heuristics (grep ;) over all our autobuild logfiles to find such offenders. Yeah, indeed, still happens sometimes. A very stupid trick, but works pretty well: when I compile the sources for the first time (to gather information to write the spec file), I pass -DXXXXXXXXXXXXXXXXXXXXXXXXXXXX (or something like that) to CFLAGS/CXXFLAGS. It's very easy to see whether it's used when the source is compiling ;)) (and it doesn't have any side effects).
I have a similar check included in our checkscripts.
I suppose you mean "our" = SUSE-internal? Is that an isolated check script for rpmbuild or is it in the buildserver ? If it's not the latter, could it be shared with us ? [...]
Note that this mail was sent to our internal packagers and was meant for them. It is only for your information for external packagers ;)
Yes, I assumed so ;))
cheers
- --
-o) Pascal Bleser http://linux01.gwdg.de/~pbleser/
/\\
A very stupid trick, but works pretty well: when I compile the sources for the first time (to gather information to write the spec file), I pass -DXXXXXXXXXXXXXXXXXXXXXXXXXXXX (or something like that) to CFLAGS/CXXFLAGS. It's very easy to see whether it's used when the source is compiling ;)) (and it doesn't have any side effects).
I have a similar check included in our checkscripts.
I suppose you mean "our" = SUSE-internal?
Yes.
Is that an isolated check script for rpmbuild or is it in the buildserver ? If it's not the latter, could it be shared with us ?
It is an isolated checkscript in the buildserver. I have attached it for reference. Ciao, Marcus
participants (5)
-
Adrian Schröter -
Dirk Mueller -
Marcus Meissner -
Pascal Bleser -
Stanislav Brabec