Differences between revisions 3 and 9 (spanning 6 versions)
⇤ ← Revision 3 as of 2007-10-11 00:16:57 →
Size: 4444
Editor: ?KeesCook
Comment:
← Revision 9 as of 2008-01-23 17:18:36 → ⇥
Size: 10096
Editor: ?KeesCook
Comment: demonstration of build differences
Deletions are marked like this. Additions are marked like this.
Line 1: Line 1:

= Mitigation Methods =		 = Using Hardening Options =

Several compile-time options (detailed below) can be used to help harden a resulting binary against memory corruption attacks, or provide additional warning messages during compiles. The "hardening-wrapper" set of scripts is designed to help provide these options without requiring packaging changes. The goal is to be able to use the wrapper on the buildds and local developer's systems to provide hardened builds.

After installing the "hardening-wrapper" package, it must be enabled:

{{{
 $ export DEB_BUILD_HARDENING=1
}}}

After that, any use of gcc, g++, or ld (e.g. through debuild or dpkg-buildpackage) will have all hardening options enabled by default. Each option can be disabled individually (via {{{export DEB_BUILD_HARDENING_[feature]=0}}}), if there are complications with the build resulting from the new options. (So far, only rare issues with stack protector and PIE support have been documented.)

To illustrate the effects of the options, a [http://svn.debian.org/wsvn/hardening/example/trivial.c?op=file trivial] C source (with [http://svn.debian.org/wsvn/hardening/example/Makefile?op=file Makefile]) is used as an example.

== DEB_BUILD_HARDENING_FORMAT (gcc/g++ -Wformat -Wformat-security) ==

Quoting the gcc man page:
  If `-Wformat` is specified, also warn about uses of format
  functions that represent possible security problems. At present,
  this warns about calls to `printf` and `scanf` functions where the
  format string is not a string literal and there are no format
  arguments, as in `printf (foo);`. This may be a security hole if
  the format string came from untrusted input and contains `%n`.
[http://en.wikipedia.org/wiki/Format_string_attack]

Default compile:
{{{
$ make trivial
cc -Wall -O2 trivial.c -o trivial
}}}

Hardened compile:
{{{
$ DEB_BUILD_HARDENING=1 make trivial
cc -Wall -O2 trivial.c -o trivial
trivial.c: In function 'main':
trivial.c:16: warning: format not a string literal and no format arguments
}}}

== DEB_BUILD_HARDENING_FORTIFY (gcc/g++ -D_FORTIFY_SOURCE=2) ==

During code generation the compiler knows a great deal of information about
buffer sizes (where possible), and attempts to replace insecure unlimited
length buffer function calls with length-limited ones. This is especially
useful for old, crufty code. Note that for this feature to be fully enabled,
the source must also be compiled with -O2 or higher.

Default build:
{{{
$ make trivial
cc -Wall -O2 trivial.c -o trivial
$ ./trivial $(perl -e 'print "A"x100')
Your first argument was: AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
Segmentation fault (core dumped)
}}}

Hardened build:
{{{
$ DEB_BUILD_HARDENING=1 make trivial
cc -Wall -O2 trivial.c -o trivial
trivial.c: In function 'main':
trivial.c:16: warning: format not a string literal and no format arguments
$ ./trivial $(perl -e 'print "A"x100')
*** buffer overflow detected ***: ./trivial terminated
}}}

== DEB_BUILD_HARDENING_STACKPROTECTOR (gcc/g++ -fstack-protector) ==

This is a mainline GCC feature, which adds safety checks against stack
overwrites. This renders many potential code injection attacks into
aborting situations. In the best case this turns code injection vulnerabilities
into denial of service or into non-issues (depending on the application).
[http://en.wikipedia.org/wiki/Stack-smashing_protection]

Default build:
{{{
$ make trivial
cc -Wall -O2 trivial.c -o trivial
$ ./trivial $(perl -e 'print "A"x100')
Your first argument was: AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
Segmentation fault (core dumped)
}}}

Hardened build (with FORTIFY disabled, since it catches the stack overflow before it happens):
{{{
$ DEB_BUILD_HARDENING=1 DEB_BUILD_HARDENING_FORTIFY=0 make trivial
cc -Wall -O2 trivial.c -o trivial
trivial.c: In function 'main':
trivial.c:16: warning: format not a string literal and no format arguments
$ ./trivial $(perl -e 'print "A"x100')
Your first argument was: AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
*** stack smashing detected ***: ./trivial terminated
}}}

== DEB_BUILD_HARDENING_PIE (gcc/g++ -fPIE, ld -pie) ==

Position Independent Executable are needed to take advantage of Address Space Layout
Randomization, supported by some kernel versions. http://en.wikipedia.org/wiki/ASLR

Default build:
{{{
$ make trivial
cc -Wall -O2 trivial.c -o trivial
$ file trivial
trivial: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), for GNU/Linux 2.6.8, dynamically linked (uses shared libs), not stripped
}}}

Hardened build:
{{{
$ DEB_BUILD_HARDENING=1 make trivial
cc -Wall -O2 trivial.c -o trivial
trivial.c: In function 'main':
trivial.c:16: warning: format not a string literal and no format arguments
$ file trivial
trivial: ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), for GNU/Linux 2.6.8, not stripped
}}}

== DEB_BUILD_HARDENING_RELRO (ld -z relro) ==

During program load, several ELF memory sections need to be written to by the linker, but can be
turned read-only before turning over control to the program. Most notably this prevents GOT overwrite
attacks.



= Notes on Memory Corruption Mitigation Methods =
Line 24: Line 148:
=== gcc -Wformat=security === === gcc -Wformat -Wformat-security ===
Line 28: Line 152:
=== gcc -pie ===

This is especially difficult to plumb into packaging in a safe way, since it requires the executable be built with -fPIC for any .o files that are linked at the end with -pie. There is some amount of performance loss, but only due to the -fPIC, which is already true for all the linked libraries.		 === gcc -pie -fPIE ===

This is especially difficult to plumb into packaging in a safe way, since it requires the executable be built with -fPIE for any .o files that are linked at the end with -pie. There is some amount of performance loss, but only due to the -fPIE, which is already true for all the linked libraries (via their -fPIC).
Line 92: Line 216:
 * -relro
 * -pie		  * -z relro
 * -pie (-fPIE)
Line 95: Line 219:
 * -Wformat -Wformat-security

Current implementation attempt at the user-space compiled hardening is [http://svn.debian.org/wsvn/hardening] which provides a gcc/g++/ld wrapper.

Using Hardening Options

Several compile-time options (detailed below) can be used to help harden a resulting binary against memory corruption attacks, or provide additional warning messages during compiles. The "hardening-wrapper" set of scripts is designed to help provide these options without requiring packaging changes. The goal is to be able to use the wrapper on the buildds and local developer's systems to provide hardened builds.

After installing the "hardening-wrapper" package, it must be enabled: 

 $ export DEB_BUILD_HARDENING=1

After that, any use of gcc, g++, or ld (e.g. through debuild or dpkg-buildpackage) will have all hardening options enabled by default. Each option can be disabled individually (via export DEB_BUILD_HARDENING_[feature]=0), if there are complications with the build resulting from the new options. (So far, only rare issues with stack protector and PIE support have been documented.)

To illustrate the effects of the options, a [http://svn.debian.org/wsvn/hardening/example/trivial.c?op=file trivial] C source (with [http://svn.debian.org/wsvn/hardening/example/Makefile?op=file Makefile]) is used as an example.

DEB_BUILD_HARDENING_FORMAT (gcc/g++ -Wformat -Wformat-security)

Quoting the gcc man page:

  • If -Wformat is specified, also warn about uses of format functions that represent possible security problems. At present, this warns about calls to printf and scanf functions where the format string is not a string literal and there are no format arguments, as in printf (foo);. This may be a security hole if the format string came from untrusted input and contains %n.

[http://en.wikipedia.org/wiki/Format_string_attack]

Default compile: 

$ make trivial
cc -Wall -O2    trivial.c   -o trivial

Hardened compile: 

$ DEB_BUILD_HARDENING=1 make trivial
cc -Wall -O2    trivial.c   -o trivial
trivial.c: In function 'main':
trivial.c:16: warning: format not a string literal and no format arguments

DEB_BUILD_HARDENING_FORTIFY (gcc/g++ -D_FORTIFY_SOURCE=2)

During code generation the compiler knows a great deal of information about buffer sizes (where possible), and attempts to replace insecure unlimited length buffer function calls with length-limited ones. This is especially useful for old, crufty code. Note that for this feature to be fully enabled, the source must also be compiled with -O2 or higher.

Default build: 

$ make trivial
cc -Wall -O2    trivial.c   -o trivial
$ ./trivial $(perl -e 'print "A"x100')
Your first argument was: AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
Segmentation fault (core dumped)

Hardened build: 

$ DEB_BUILD_HARDENING=1 make trivial
cc -Wall -O2    trivial.c   -o trivial
trivial.c: In function 'main':
trivial.c:16: warning: format not a string literal and no format arguments
$ ./trivial $(perl -e 'print "A"x100')
*** buffer overflow detected ***: ./trivial terminated

DEB_BUILD_HARDENING_STACKPROTECTOR (gcc/g++ -fstack-protector)

This is a mainline GCC feature, which adds safety checks against stack overwrites. This renders many potential code injection attacks into aborting situations. In the best case this turns code injection vulnerabilities into denial of service or into non-issues (depending on the application). [http://en.wikipedia.org/wiki/Stack-smashing_protection]

Default build: 

$ make trivial
cc -Wall -O2    trivial.c   -o trivial
$ ./trivial $(perl -e 'print "A"x100')
Your first argument was: AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
Segmentation fault (core dumped)

Hardened build (with FORTIFY disabled, since it catches the stack overflow before it happens): 

$ DEB_BUILD_HARDENING=1 DEB_BUILD_HARDENING_FORTIFY=0 make trivial
cc -Wall -O2    trivial.c   -o trivial
trivial.c: In function 'main':
trivial.c:16: warning: format not a string literal and no format arguments
$ ./trivial $(perl -e 'print "A"x100')
Your first argument was: AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
*** stack smashing detected ***: ./trivial terminated

DEB_BUILD_HARDENING_PIE (gcc/g++ -fPIE, ld -pie)

Position Independent Executable are needed to take advantage of Address Space Layout Randomization, supported by some kernel versions. http://en.wikipedia.org/wiki/ASLR

Default build: 

$ make trivial
cc -Wall -O2    trivial.c   -o trivial
$ file trivial
trivial: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), for GNU/Linux 2.6.8, dynamically linked (uses shared libs), not stripped

Hardened build: 

$ DEB_BUILD_HARDENING=1 make trivial
cc -Wall -O2    trivial.c   -o trivial
trivial.c: In function 'main':
trivial.c:16: warning: format not a string literal and no format arguments
$ file trivial
trivial: ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), for GNU/Linux 2.6.8, not stripped

DEB_BUILD_HARDENING_RELRO (ld -z relro)

During program load, several ELF memory sections need to be written to by the linker, but can be turned read-only before turning over control to the program. Most notably this prevents GOT overwrite attacks.

Notes on Memory Corruption Mitigation Methods

User Space

Stack Protector

gcc's -fstack-protector attempts to detect when a stack has been overwritten and aborts the program. Ubuntu has had this enabled by default since Edgy. [https://wiki.ubuntu.com/GccSsp Some programs] do not play nice with it, and can be worked around with -fno-stack-protector. It would be nice to enable this by default, and for gcc to only attempt to use it when libc is being linked against.

Already done in sendmail.

heap protection

In glibc2.5, no additional work needed.

libc pointer encryption

Making its way into mainline glibc, unsure of current state.

gcc -D_FORTIFY_SOURCE=2 -O2

Compile-time protection against static sized buffer overflows. No known regressions or performance loss. This should be enabled system-wide

gcc -Wformat -Wformat-security

While not all programs correctly implement the printf hints (like [http://developer.gnome.org/doc/API/2.0/glib/glib-Miscellaneous-Macros.html glib's G_GNUC_PRINTF macro]), adding this will at least call out simple printf format string vulnerabilities. Any programs whose builds become "noisy" as a result, should be fixed anyway.

gcc -pie -fPIE

This is especially difficult to plumb into packaging in a safe way, since it requires the executable be built with -fPIE for any .o files that are linked at the end with -pie. There is some amount of performance loss, but only due to the -fPIE, which is already true for all the linked libraries (via their -fPIC).

Already done with openssh, sendmail.

gcc -z relro

Already done with sendmail.

Kernel Space

non-exec memory segmentation (ExecShield)

Stops execution of code in heap/stack. i386 specific (nx already does this for amd64), and introduces some small level of performance loss (5% for CPU-bound). Some people have worked on getting it pushed into the mainline kernel. Current state unknown -- would be very handy to have due to the popularity of i386. Marcus Better may be willing to continue to maintain the patchset for Debian.

Some applications appear to break when run in the protected memory layout. Most of these issues should be fixed due to RH (and SUSE?) already running with these protections.

Additional work for user-space is identifying programs that build assembly but fail to explicitly mark their stack as non-exec (gnupg, for example).

-fstack-protector

Is available for amd64 builds:

  • config CC_STACKPROTECTOR

runtime memory allocation validation

Detect double-frees in kernel space. No idea where it stands.

Address Space Layout Randomization

  • mmap: in mainline
  • stack: in mainline
  • vdso: in since 2.6.18 (COMPAT_VDSO disables it)
  • heap/exec: in -mm, scheduled for 2.6.24

Having heap/exec ASLR is a prerequisite for -pie being useful. Presently, openssh is compiled with -pie.

/proc/$pid/maps protection

Present in 2.6.22, requires sysctl toggle (kernel.maps_protect = 1).

/dev/mem protection

Not sure where it stands for mainline inclusion.

From the GRSecurity patchset, protections against hardlink/symlink creation/following in world-writable areas. (Solves tmp races.) May potentially break things like postfix that manipulation hardlinks? Breaks POSIX. Getting taken in mainline may be possible with a build-time or proc toggle.

[http://lkml.org/lkml/2005/3/10/101] [http://lkml.org/lkml/2005/4/18/167]

chroot, dmesg, fifo protections

Also from GRSecurity patchset.

Build Changes

Integrated build variables

Need to be able to enable/disable compile-time protections via debian/rules elements:

  • -fstack-protector
  • -z relro
  • -pie (-fPIE)
  • -D_FORTIFY_SOURCE=2 -O2
  • -Wformat -Wformat-security

Current implementation attempt at the user-space compiled hardening is [http://svn.debian.org/wsvn/hardening] which provides a gcc/g++/ld wrapper.

Documentation