Why GCC stack protector is not enabled in Arch?

stolowski · 2010-03-27 17:45:37

Hello,

Does anyone have a good explanation on why GCC stack smashing protection (SSP) is not enabled by default for Arch packages? I think security measures are necessary nowadays and this includes not only servers, but workstations too. I'm concerned about security of my workstation and try to make it more bullet-proof (have been using Tomoyo Linux MAC for some time and would recommended it to anyone willing to use a MAC implementaion that is easier to use than SELinux) and discovering that SSP is not enabled in Arch was like a big *wow* - why? Debian and Ubuntu have it, I think Fedora and many others have it too... I think SSP should be enabled by default in every distro as a minimum security measure... I know I can add -fstack-protector to makepkg.conf, but this means recompiling a lot of core stuff...

Any thoughts?

Allan · 2010-03-27 18:23:49

File a feature request at the bug tracker.

Edit: it appears there is a ~5% performance hit by enabling that option. So this seems unlikely...

stolowski · 2010-03-27 22:44:44

Allan wrote:

File a feature request at the bug tracker.
Edit: it appears there is a ~5% performance hit by enabling that option. So this seems unlikely...

Well, security comes at a price . To me 5% is irrelevant given the advantages it brings, but of course I can imagine people considering this as an issue. Anyway, I think I'll file a feature request for this and let (you) developers decide...
Where did you find performance analysis of SSP?

Allan · 2010-03-27 23:25:07

stolowski wrote:

Where did you find performance analysis of SSP?

Google.

stolowski · 2010-03-28 12:08:10

Feature request has been added. Anyone interested in such enhancement, please speak up and vote for this request:
http://bugs.archlinux.org/task/18864

Thanks.

astenorh · 2011-01-16 10:18:05

Actually this is mentioned in one of the Linux Plus magazine.

It shows that even stack smashing protection can be hacked in some cases, and that other means should be used to provide proper security. For hacking apparently all you need is some patience and GDB.

As a better mean of security, the magazine mentions making pages of memory non-writable or non-executable when appropriate i.e. the NX bit (64 bit architecture feature) if I am not mistaken, and memory location randomization ASLR - a kernel feature. (These two features are the one advertised by Ubuntu for their server security). And it looks like Arch Linux enables ASLR by default. So there is some decent security against stack smashing.

http://lpmagazine.org/magazine/1383-mak … nux-secure

Last edited by astenorh (2011-01-16 10:18:32)

zebraz · 2011-04-06 01:10:45

"It shows that even stack smashing protection can be hacked in some cases, and that other means should be used to provide proper security. For hacking apparently all you need is some patience and GDB."

When implemented properly, and without info leaks, stack smashing protection is the best method of protecting against stack overflows.

"As a better mean of security, the magazine mentions making pages of memory non-writable or non-executable when appropriate i.e. the NX bit (64 bit architecture feature) if I am not mistaken, and memory location randomization ASLR - a kernel feature. (These two features are the one advertised by Ubuntu for their server security). And it looks like Arch Linux enables ASLR by default. So there is some decent security against stack smashing."

Well, no. These won't help protect against most stack overflows, but they do make it more difficult for an attacker. At the moment, there is no .text randomisation in arch:

# cat /proc/self/maps | grep cat
08048000-08051000 r-xp 00000000 08:04 4849690 /bin/cat
08051000-08052000 rw-p 00009000 08:04 4849690 /bin/cat
# cat /proc/self/maps | grep cat
08048000-08051000 r-xp 00000000 08:04 4849690 /bin/cat
08051000-08052000 rw-p 00009000 08:04 4849690 /bin/cat
# cat /proc/self/maps | grep cat
08048000-08051000 r-xp 00000000 08:04 4849690 /bin/cat
08051000-08052000 rw-p 00009000 08:04 4849690 /bin/cat

So an attacker can simply use ret2 method to exploit a stack overflow:
http://en.wikipedia.org/wiki/Return-to-libc_attack

Even if .text randomisation were turned on, many applications require fixed addresses and/or rwx segments of memory in order to execute properly. These include things like firefox (with chrome's JIT JavaScript engine enabled-- the default) as well as java and many other exposed things.

Keep in mind that stack overflows are one of the simplest vulnerability classes to exploit. Even with grsec/pax ASLR and NX/SEGMEXEC (which is far in excess of what is installed on linux), GCC stack smashing protection is required to prevent stack overflows.

ngoonee · 2011-04-06 02:02:15

The best way to get things moving would be to:-
1) comment on the bug (I see you've done this already)
2) Find some dev who's interested in supporting the change. Actually implementing it is easy, but someone would have to fix the bugs which arise from it (since we use gcc for, you know, just about everything?).

2) is the most difficult part, I think. [arch-genera] may be the best place to get buy-in from the devs (not many of them read the forums. Well, Allan does but he operates in a parallel universe with a different concept of time).

Allan · 2011-04-06 08:32:30

I'm here!

It will get done when I have time to add it... that means when we have a stable toolchain (i.e. not now due to gcc-4.6 and all the LTO stuff to sort out requiring backports to binutils etc... - plenty of test suite failures to fix).

Then I need to add the flags (which requires some fun as some of the toolchain can not be built with them) and then test building at least all of [core].

And this also has to coincide with a time when we have other major rebuilds to do or I am not too busy at work or...

Awebb · 2011-04-06 09:28:46

So that 5% performance hit is not an issue anymore?

Allan · 2011-04-06 11:13:26

Its more of a 1.3% hit on average, which is acceptable. If someone does not like that, they are probably using ABS to rebuild with ricer CFLAGS anyway.

ngoonee · 2011-04-06 12:08:37

Allan wrote:

Its more of a 1.3% hit on average, which is acceptable. If someone does not like that, they are probably using ABS to rebuild with ricer CFLAGS anyway.

tut tut... watch your language please =p

Arch Linux

#1 2010-03-27 17:45:37

Why GCC stack protector is not enabled in Arch?

#2 2010-03-27 18:23:49

Re: Why GCC stack protector is not enabled in Arch?

#3 2010-03-27 22:44:44

Re: Why GCC stack protector is not enabled in Arch?

#4 2010-03-27 23:25:07

Re: Why GCC stack protector is not enabled in Arch?

#5 2010-03-28 12:08:10

Re: Why GCC stack protector is not enabled in Arch?

#6 2011-01-16 10:18:05

Re: Why GCC stack protector is not enabled in Arch?

#7 2011-04-06 01:10:45

Re: Why GCC stack protector is not enabled in Arch?

#8 2011-04-06 02:02:15

Re: Why GCC stack protector is not enabled in Arch?

#9 2011-04-06 08:32:30

Re: Why GCC stack protector is not enabled in Arch?

#10 2011-04-06 09:28:46

Re: Why GCC stack protector is not enabled in Arch?

#11 2011-04-06 11:13:26

Re: Why GCC stack protector is not enabled in Arch?

#12 2011-04-06 12:08:37

Re: Why GCC stack protector is not enabled in Arch?

Board footer