You are not logged in.

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

stolowski
Member
From: Poland, Bydgoszcz
Registered: 2009-09-23
Posts: 18
Website

Why GCC stack protector is not enabled in Arch?

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?

Offline

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

Allan
Member
From: Brisbane, AU
Registered: 2007-06-09
Posts: 10,903
Website

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

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...

Offline

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

stolowski
Member
From: Poland, Bydgoszcz
Registered: 2009-09-23
Posts: 18
Website

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

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 wink. 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?

Offline

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

Allan
Member
From: Brisbane, AU
Registered: 2007-06-09
Posts: 10,903
Website

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

stolowski wrote:

Where did you find performance analysis of SSP?

Google.

Offline

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

stolowski
Member
From: Poland, Bydgoszcz
Registered: 2009-09-23
Posts: 18
Website

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

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.

Offline

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

astenorh
Member
From: Belgium
Registered: 2010-08-18
Posts: 5

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

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)

Offline

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

zebraz
Member
Registered: 2011-04-05
Posts: 1

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

"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.

Offline

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

ngoonee
Forum Fellow
From: Between Thailand and Singapore
Registered: 2009-03-17
Posts: 7,244

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

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-Volunteer on the (topic being discussed) mailn lists. You never get the people who matters attention on the forums.
jasonwryan-Installing Arch is a measure of your literacy. Maintaining Arch is a measure of your diligence. Contributing to Arch is a measure of your competence.
Griemak-Bleeding edge, not bleeding flat. Edge denotes falls will occur from time to time. Bring your own parachute.

Offline

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

Allan
Member
From: Brisbane, AU
Registered: 2007-06-09
Posts: 10,903
Website

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

I'm here!   tongue

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...

Offline

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

Awebb
Member
Registered: 2010-05-06
Posts: 5,316

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

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

Offline

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

Allan
Member
From: Brisbane, AU
Registered: 2007-06-09
Posts: 10,903
Website

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

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.

Offline

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

ngoonee
Forum Fellow
From: Between Thailand and Singapore
Registered: 2009-03-17
Posts: 7,244

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

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


Allan-Volunteer on the (topic being discussed) mailn lists. You never get the people who matters attention on the forums.
jasonwryan-Installing Arch is a measure of your literacy. Maintaining Arch is a measure of your diligence. Contributing to Arch is a measure of your competence.
Griemak-Bleeding edge, not bleeding flat. Edge denotes falls will occur from time to time. Bring your own parachute.

Offline

Board footer

Powered by FluxBB