Arch Linux

Please read this before reporting a bug:
https://wiki.archlinux.org/index.php/Reporting_Bug_Guidelines

Do NOT report bugs when a package is just outdated, or it is in Unsupported. Use the 'flag out of date' link on the package page, or the Mailing List.

REPEAT: Do NOT report bugs for outdated packages!
Tasklist

FS#18864 - Consider enabling GCC's stack-smashing protection (ProPolice, SSP) for all packages

Attached to Project: Arch Linux
Opened by Pawel Stolowski (stolowski) - Sunday, 28 March 2010, 12:06 GMT
Last edited by Allan McRae (Allan) - Saturday, 20 August 2011, 09:10 GMT
Task Type Feature Request
Category Packages: Core
Status Closed
Assigned To Jan de Groot (JGC)
Pierre Schmitz (Pierre)
Aaron Griffin (phrakture)
Thomas Bächler (brain0)
Dan McGee (toofishes)
Allan McRae (Allan)
Architecture All
Severity Low
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 24
Private No

Details

Description:

Please consider enabling stack smashing protection (aka ProPolice) for all Arch packages. It adds only little overhead, but users will benefit from increased
security of the default Arch installation and will be protected against a range of common software bugs and their exploitation.

Additional info:

Stack smashing protector is a GCC extension for protecting applications from stack-smashing attacks. It is available in stock GCC.
It can be enabled by -fstack-protector or -fstack-protector-all compile flags.
More information here: http://www.research.ibm.com/trl/projects/security/ssp/

This task depends upon

Closed by  Allan McRae (Allan)
Saturday, 20 August 2011, 09:10 GMT
Reason for closing:  Implemented
Comment by Allan McRae (Allan) - Sunday, 28 March 2010, 12:32 GMT
I can not find any current estimates of the overhead. Some estimates put an upper bound of the overhead at 8%. OpenBSD claims 1.3% on average.
Comment by Pawel Stolowski (stolowski) - Monday, 29 March 2010, 08:09 GMT
This may be helpful:
https://wiki.ubuntu.com/GccSsp

They implemented it in 2006 and the wiki lists some problems they encountered.
Comment by Allan McRae (Allan) - Thursday, 15 April 2010, 02:50 GMT Comment by Thomas Bächler (brain0) - Thursday, 15 April 2010, 08:00 GMT
What I know about this topic: the -fstack-protector option has been enabled in our _kernel_ builds for at least half a year.
Comment by Pierre Schmitz (Pierre) - Wednesday, 06 October 2010, 17:31 GMT
What's the status here? I have no real objection against enabling this option.
Comment by dyscoria (dyscoria) - Wednesday, 01 December 2010, 01:20 GMT
This is probably most significant for x86 as there is absence of NX bit (in non-PAE kernels) and reduced ASLR (compared to 64bit). Thus there is little protection against buffer overflows. There is less gain to be had for x86_64.

Also, -fstack-protector-all includes adding protection to functions whose buffer would normally be below the size limit for stack smashing protection.
Comment by Allan McRae (Allan) - Wednesday, 01 December 2010, 02:01 GMT
My plans for this are:

1) add -fstack-protector (undecided about -all) and -D_FORTIFY_SOURCE=2 to our C{,XX}FLAGS in makepkg.conf. I will not take the approach of some other distros and patch these to be the default in our gcc build as that is not following upstream. (I know the gcc package currently does patch for hash-style but that will change in the future...)

2) consider adding -fPIE to our C{,XX}FLAGS on x86_64 only. Definitely not on i686...

3) consider adding -Wl,-z,now -Wl,-z,relro to our LDFLAGS

4) do a complete rebuild of the toolchain (and maybe some other "core" packages) with those flags and test. There still appears to be some areas of gcc that should not be built with these options (specifically -fstack-protector), so this will need to be done in a time where the toolchain is not expecting updates so it can receive some decent testing. Perhaps between binutils-2.21/glibc-2.13 and gcc-4.6 will be a good time.
Comment by dyscoria (dyscoria) - Wednesday, 01 December 2010, 08:43 GMT
How about -Wformat -Wformat-security? I believe it's only useful at compile time...seems like it shouldn't break much.

edit: should -pie be added to LDFLAGS as well (for x86_64)?
Comment by Allan McRae (Allan) - Tuesday, 07 December 2010, 02:55 GMT
-Wformat -Wformat-security are really only good for upstream developers. They will make little difference at a distribution level as I doubt there will be any real push to fix the extra warnings they generate.

Probably -Wl,-pie should of wiht -fPIE on x86_64.
Comment by dyscoria (dyscoria) - Tuesday, 04 January 2011, 20:43 GMT
I just noticed that Google have updated their Chrome system hardening page:
http://www.chromium.org/chromium-os/chromiumos-design-docs/system-hardening

They have recommended this for hardening the toolchain:

Ensure that we don't optimize out NULL pointer checks as mmap(0) tricks are the current trend in kernel exploitation.
-fno-delete-null-pointer-checks

So their final list looks like this:

The userland toolchain should enforce a number of requirements (which will need benchmarking):
-fno-delete-null-pointer-checks
-fstack-protector: stack canary
-pie: relocatable executables (and marked ET_DYN)
-Wl,-z,relro: read-only relocations
FORTIFY_SOURCE
Comment by Lukas Fleischer (lfleischer) - Friday, 18 March 2011, 00:22 GMT
Any progress here?
Comment by mark phillips (zebraz) - Wednesday, 06 April 2011, 01:43 GMT
Hi,

This is pretty important from a security perspective. NX and partial ASLR do not protect against stack overflows, even on x86_64.

Any update here? Anything I can do to help?
Comment by Allan McRae (Allan) - Wednesday, 06 April 2011, 08:34 GMT
It is on my todo list... now is not the time as I still have issues with the gcc-4.6 update and test-suite failures.
Comment by Raghavendra D Prabhu (rprabhu) - Friday, 15 April 2011, 14:50 GMT
Currently I use,
-fstack-protector -Wl,-z,relro -D_FORTIFY_SOURCE=2 in my makepkg.conf. I haven't seen any builds break because of this. Full RELRO ie. with -Wl,-z,now,-z,relro is known to cause slowdown since it disables the lazy loading used by the linker. Coming to PIE, this would require changes to both cflags and ldflags and can break builds which use inline assembly among others, and also library only builds which require fPIC. I also recommending using
checksec.sh from http://www.trapkit.de/tools/checksec.html to audit the system before and after. Speaking of kernel, stack protection must be enabled already as stated before and sysctl kernel.randomize_va_space should be 2 if set otherwise.
Comment by Kristoffer Tidemann (ktide) - Friday, 15 April 2011, 19:31 GMT
Sadly, this is pretty hard to get *completly* right without modifying the toolchain. (Especially PIE, but also because there are still a lot of Packages that don't like our CFLAGS or don't use them at all.)

Using -D_FORTIFY_SOURCE=2 -fstack-protector (Afaik Debian adds --param ssp-buffer-size=4 too?)
globally seems to be pretty easy to pull off and should probably be enabled as soon as possible. Only a few builds will break, that will be an easy clean up though.

Wl,-z,relro should probably be global. Wl,-z,now could suck for startup times of big programs, so enable only for critical and/or small stuff.

(I also propose the usage of -Wl,-O1, while irrelevant to the security aspect, it seem's to provide enough benefits that it's used by default on Gentoo.)

Here's a >small< shell script that can be used to verify success on individual files - taken from one of the Debian hardening packages: http://sprunge.us/FZGK?sh

For reference, here's the output of the script mentioned by Raghavendra from someone running Ubuntu (Maverick): http://pastie.org/private/ptexeq8zfyyo16vh0q
Comment by Kristoffer Tidemann (ktide) - Wednesday, 04 May 2011, 22:09 GMT
Updates on this? Building everything with -D_FORTIFY_SOURCE=2 -fstack-protector and -Wl,-z,relro - noticed no performance penalty or regressions whatsoever.

After this is done, nominate candidates for "advanced" flags such as -fPIE. (I.e ssh, postfix etc.)
Comment by Dan McGee (toofishes) - Wednesday, 04 May 2011, 22:27 GMT Comment by Sverd Johnsen (sjohnsen) - Sunday, 10 July 2011, 10:50 GMT
What's the status quo on this one? I've been basically doing the same thing as my friend Kristoffer and noticed little problems as long as you stay far away from the toolchain and kernel stuff with those flags.

Given that I tend to have a lot of beefy hardware around me implementing this for my own was rather easy. Sticking it in makepkg.conf is not as good as patching the toolchain due to packages that ignore the environment etc. but it's a very good start.

Right now, going from pretty much any major distribution to Arch Linux comes with a real loss of security - not even considering the lack of package signing which saw some good progress in the past weeks for which I'm very glad :)

I hope the Arch Linux developers can find a away to get this into the packaging process soon.

Want: -D_FORTIFY_SOURCE=2 -fstack-protector (--param ssp-buffer-size=4 seems to be popular across distributions.) and -Wl,-z,relro.

Thanks for reading.

Comment by Allan McRae (Allan) - Sunday, 10 July 2011, 11:16 GMT
There were no objections to this becoming our new C{,XX}FLAGS/LDFLAGS on the mailing list so this will be the new default:

CFLAGS="-march=XXX -mtune=generic -O2 -pipe -fstack-protector --param=ssp-buffer-size=4 -D_FORTIFY_SOURCE=2"
LDFLAGS="-Wl,-O1,--sort-common,--as-needed,-z,relro,--hash-style=gnu"

The glibc-2.14 toolchain has only been out of [testing] for a week or two. I'd like to wait another couple of weeks before I adjust the toolchain PKGBUILDs to deal with these flags. There seems to be no big glibc/binutils/gcc updates for a while so this is probably a good window to do this.

There will be no patching of the toolchain to make these the default. If upstream considered that an option, it would be done there (like how configuring --hash-style has been done for gcc-4.7...). Packages that ignore CFLAGS/LDFLAGS are either broken upstream, broken in packaging, or deliberately ignoring them and should be dealt with on an individual basis. (FYI, around 5% of [core] ignores CFLAGS and 10% LDFLAGS)
Comment by Allan McRae (Allan) - Sunday, 14 August 2011, 12:57 GMT
This is in [testing] now. pacman-3.5.4-4 has the CFLAGS/LDFLAGS given in the comment above and the toolchain packages have been adjusted as necessary and rebuild using these flags.

Loading...