[ Docs | Tools | Advisories | Full-Disclosure ]

Introduction

This document outlines how to build a version of GCC for the Sparc and x86 architectures that produces 32-bit executables with the Stack-Smashing Protector (SSP), otherwise known as ProPolice.

This technology has been implemented in a number of open-source operating systems, such as OpenBSD, but requires modification to work in a Solaris environment.

Whilst we cannot rebuild the core OS itself without source code, we can still make use of this tool to compile popular third-party applications to raise the bar against stack-smashing exploits directed at Solaris machines.

Update: These instructions apply to gcc 2.95.3 only. Please see http://grok.org.uk/tools/ssp/ for other supported versions.

Prerequisites

The following files are required for the compiler build:

GCC 2.95.3: [ tar.gz | md5 ]

Hiroaki Etoh's ProPolice patch: [ tar.gz | md5 ]

My patch to enable Solaris functionality: [ patch | md5 | asc ]

(My PGP key is available here and on various keyservers.)

Patch details

The original SSP patch will function correctly on Solaris as far as detecting and stopping a stack-smashing attack, and reporting the error to stderr. However, one of the valuable features of the patch is the ability to notify users via syslog, and the code assumes a *BSD-style /dev/log socket interface, which is not the case with Solaris.

My patch simply removes this requirement in favour of a call to the syslog(3C) function, and removes a handful of included header files and definitions that have no relevance in a Solaris environment for the sake of tidiness. The other alteration is to patch the i386/t-sol2 and sparc/t-sol2 files rather than the linux-specific file in the configuration directory to add the HAVE_SYSLOG definition. (I chose to do this so that I preserved the original #ifdef structure of the original).

The patch has been verified to work under a Solaris 8 (Sparc) environment on Ultra5 and Ultra60 architectures, and additionally on a dual PIII x86 platform.

Building the compiler

Having downloaded and verified the archives mentioned above, the following simple procedure should be followed:

# gzip -cd gcc-2.95.3.tar.gz | tar xf -
# cd gcc-2.95.3/gcc
# gzip -cd ../../protector-2.95.3-20.tar.gz | tar xf -
# gpatch  < ../../propolice-2.95.3-20-solaris.patch 
# gpatch -p1 < protector.dif
# cd ..
# ./configure --prefix=/opt/local/gcc --enable-languages=c,c++
# gmake bootstrap
# gmake check
# gmake install

Note: You should use the GNU patch and make utilities for best results. Testing requires extra programs such as DejaGNU to be present.

If all has gone well, you should now have an SSP-enabled GCC in /opt/local/gcc/bin. To enable the stack protection feature, specify CFLAGS=-fstack-protector when compiling your source code.

Testing

Testing is simple: simply smash the stack! Construct a program such as this:

/* test-propolice.c */
#define OVERFLOW "This is longer than 10 bytes"

int main (int argc, char *argv[]) {
    char buffer[10];
    strcpy(buffer, OVERFLOW);
    return 0;
}

Then compile and run as follows:

# gcc -fstack-protector -o test-propolice test-propolice.c
# ./test-propolice
stack smashing attack in function main

You should also see a syslog message similar to this:

test-propolice[19961]: [ID 702911 auth.crit] stack smashing attack in function main

Notes

Whilst this patch provides a great early-warning system, it should be used in conjunction with existing Solaris features, such as the non-executable stack flags for /etc/system:

set noexec_user_stack = 1 
set noexec_user_stack_log = 1

In addition, applications should be linked against the non-executable stack mapfile provided with Solaris ld(1).

gcc -fstack-protector -Wl,-M,/usr/lib/ld/map.noexstk -o test-propolice test-propolice.c

These protections are discussed in more detail in Sun's Solaris Operating Security Environment blueprint.

Conclusion

With a few simple changes, the benefits of the SSP patch can be extended to a Solaris environment. It is recommended that applications are built and tested without the protection initially, and then recompiled for comparison purposes. It is also worth noting that the use of SSP introduces a requirement for a /dev/urandom device, so a patch such as 112438-xx should be applied to the OS (or 112439-xx for x86). It is particularly important to remember to add these device nodes for applications running under a chroot(1M) jail, too.

John Cartwright <johnc@grok.org.uk>