Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.

Bug 80002

Summary: Please add stack smashing protection (e.g., IBM ProPolice)
Product: [Retired] Red Hat Linux Reporter: David A. Wheeler <dwheeler>
Component: gcc3Assignee: Jakub Jelinek <jakub>
Status: CLOSED WONTFIX QA Contact:
Severity: medium Docs Contact:
Priority: medium    
Version: 8.0CC: barryn, dnielsen, mitr
Target Milestone: ---Keywords: FutureFeature
Target Release: ---   
Hardware: All   
OS: Linux   
Fixed In Version: Doc Type: Enhancement
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2004-10-07 13:37:03 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:

Description David A. Wheeler 2002-12-18 17:45:40 UTC
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; SunOS sun4u; en-US; rv: Gecko/20020518

Description of problem:
The most common type of security vulnerability is a
buffer overflow of the stack; exploiting this vulnerability is called
"stack smashing". Stack smashing usually
allows attackers to completely take over the vulnerable application,
and often the entire machine, so they're extremely dangerous.
Although finding individual vulnerabilities is worthwhile, I
believe Red Hat should include mechanisms to reduce the
effectiveness of unknown stack overflow vulnerabilities.

Thus, please add mechanisms to protect against stack smashing,
and please at least use them on the major network-exposed servers
(Apache, openssh, sendmail, Postfix, etc.) & possibly all
setuid root programs.  The text below adds more detail.

A few years ago, Crispen Cowan developed a technique to do this
called "StackGuard" - it prevents attackers from taking over a
program via stack overflows (attackers can halt the program,
but that's it). This was implemented as a gcc patch; see:
Basically, to protect a program, you recompile the program
with a modified gcc & use a modified library; this can all
be controlled by compile-time switches.
Immunix is essentially a Red Hat, with Stackguard used to
recompile everything among other changes, so this is clearly
a possibility.

More recently, IBM has developed patches for gcc called
"ProPolice" that use the same approach, but with some refinements.
Like StackGuard, ProPolice
is a GCC (Gnu Compiler Collection) extension for
protecting applications from stack-smashing attacks. However,
Propolice does some reordering to improve protection, and it
protects functions more selectively to improve performance.
Also, the original implementation of StackGuard changed the
framesize, which meant that there were problems using the
symbolic debugger; ProPolice doesn't have that problem.

OpenBSD has already added ProPolice to their distribution, see:
The IBM website on ProPolice includes information on how to
build Red Hat Linux and FreeBSD with ProPolice.

Microsoft has already built a similar capability into their
compiler, and I understand that they're using it to prevent
future stack smashing attacks from having as strong an effect.

I don't care much about "StackGuard vs. ProPolice"
(vs. some other solution).  My real concern is that I'd like
to see Linux distributions have a stronger, multi-layer defense
against attackers.

Just think of the positive spin/publicity.  "Buy our next version,
it now includes enhanced security to protect against
stack overflow attacks."  I think it could be enabled by default,
but at least protect the most critical components to start with.

Version-Release number of selected component (if applicable):

How reproducible:

Steps to Reproduce:

Additional info:

Comment 1 Richard Henderson 2004-10-05 21:24:44 UTC
*** Bug 133031 has been marked as a duplicate of this bug. ***

Comment 2 Jakub Jelinek 2004-10-07 13:37:03 UTC
We are going to add object size checking instead, see