• Student: OliverPinter <op@{free,hardened}bsd.org>
• Mentor: PedroGiffuni pfg@FreeBSD.org
• Build status: [[http://jenkins.hardenedbsd.org:8180/jenkins/job/opBSD-11-fortify-amd64/lastCompletedBuild/badge/icon

Buffer overflows are the common origin of many security vulnerabilities, if we could catch these type of errors, then we would be able to protect against buffer overflows and buffer overflow based ROP attacks.
In part of this project I plan the following two phases:
First Phase: Implement FORTIFY_SOURCE, a gcc extension (also partially supported in clang), where the compiler's builtin object size informations is used by the C library to detect buffer overflows. The extension is known to be supported already by GNU libc, Apple’s Xcode, Android’s bionic libc, and NetBSD’s libc. This extension causes no secondary effects on the generated code but adds lightweight buffer checking during the compile and runtime. Second Phase (NOT TO BE DONE): Implement standard C11 Boundary checking Extensions to the C Library Part I: Bounds-checking interfaces[1][2] with their corresponding unit tests. These extensions are rather controversial but they are already implemented in commercial compilers like Microsoft Visual C and would be very useful in the future to port software from that platform. Part of this code could be useful in complementing the checks developed in the first phase and could be considered for future research.

WE THOUGHT WE MIGHT FIND THE TIME TO AT LEAST START THE SECOND PHASE BUT AFTER RECONSIDERING, THE FIRST PART IS SUFFICIENT FOR THIS GSOC PROJECT.

• Implement FORTIFY_SOURCE extension in libc.
• Android’s Bionic libc provides a reference implementation under a BSD License.
• Tests implemented extensions by building world to detect vulnerabilities.
• Test ports that already know about FORTIFY_SOURCE like mozilla and vim.

• Implement C11 extensions, described in TR 24731-1 [1][2]
• New functions must be documented, probably along within the related man pages.
• Safeclib provides a reference implementation under an MIT license.
• Provide unit tests related to implemented extensions.
• Bring FreeBSD one step closer to support C11 completely in the base system.

• Review if we can re-use phase 2 into phase 1.

(implement FORTIFY_SOURCE)

• Bounds range checking.
• Basic exploitation checking.
• Kyua tests.

(enhance FORTIFY_SOURCE - reformulated)

• General build testing: should work with base gcc and clang.
• Report and fix Buffer Overflows in base.
• Basic ports build testing.
• extend build support for other frameworks (sanitizers?).

https://reviews.freebsd.org/D3043

https://github.com/opntr/opBSD/tree/op/gsoc2015/fortify

[G] http://bxr.su/

[G] http://src.illumos.org/source/

[F] https://github.com/android/platform_bionic/tree/master/libc/bionic

[F] https://copperhead.co/2015/07/27/hardening-bionic

[F] https://android.googlesource.com/platform/bionic/+/16d1af167f8e36a9aa4a07ae77034ad519b00463

[F] https://llvm.org/bugs/show_bug.cgi?id=5028

[F] https://llvm.org/bugs/show_bug.cgi?id=23277

[F] https://llvm.org/bugs/show_bug.cgi?id=23280

[F] https://svnweb.freebsd.org/base/head/contrib/gcc/builtins.def?revision=258428&view=markup#l704

[F] http://cvsweb.netbsd.org/bsdweb.cgi/src/tests/lib/libc/ssp/ - netbsd test cases

[F] http://isisblogs.poly.edu/2011/04/11/fortify_source-semantics/

[F] https://securityblog.redhat.com/2014/03/26/fortify-and-you/

[F] https://idea.popcount.org/2013-08-15-fortify_source/

[F] http://phrack.org/issues/67/9.html

[F][clang] http://lists.cs.uiuc.edu/pipermail/cfe-commits/Week-of-Mon-20140915/115049.html

[F][clang] https://android.googlesource.com/platform/bionic/+/829c089f83ddee37203b52bcb294867a9ae7bdbc

[F][clang] https://android.googlesource.com/platform/bionic/+/16d1af167f8e36a9aa4a07ae77034ad519b00463

[F][clang] https://android.googlesource.com/platform/bionic/+/7cc779f15c524e1622f7d5b1c7e82e6ffc6677fd

[F][E] https://github.com/jsonn/src/tree/b89bad92261a943f900d7235ae50a7326ccd5062/include/ssp

[E] http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1225.pdf n1225.pdf

[E] http://www.open-std.org/JTC1/SC22/WG14/www/docs/n1173.pdf n1173.pdf

[E] https://msdn.microsoft.com/en-us/library/wd3wzwts.aspx

[E] https://gustedt.wordpress.com/2013/02/04/runtime-constraint-violations/

[E] http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1255.pdf

• Netbsd has updated their stack smash protector related files (${NETBSDSRC}/lib/libc/misc/stack_protector.c, which contains the __fail(...) and __chk_fail(...) functions. I plan to update these functions from NetBSD too.
• Other thing, is to factor out the __fail(...) and __chk_fail(...) to common place, and add them to libc_prive.h or security/common.h. After this change, we could use them from ssp and fortify.
• The headers should placed in the lib/libc/include/security/{stack_protector,fortify_source,common}.h files.

• FreeBSD libc's headers live here:

• what is right place for the newly added __*_chk symbols: FBSD_1.4 or FBSDprivate_1.0 - in first sight FBSD_1.4 because they should be accessible from any library

• editors/emacs* - misused umask() parameter - https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=202574
• mail/ifile - broken #undef OPTIMIZE - https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=202572
• hyperv tools - uninitialized parameter - https://github.com/freebsd/freebsd/commit/4485ab4d3d63c821390eecb708c6ba6bfccdbe8f
• sys build framework - badly passed compiler parameter - https://github.com/freebsd/freebsd/commit/057f55aa4b0390ec8926744ec9dbac8dde9dfa99
• wall, syslogd - buffer overflow - https://github.com/freebsd/freebsd/commit/8597d814df1fcc6d7e612a9da2dfc99025f98867
• libdtrace - buffer overflow - https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=201657

The GSoC is over and we are satisfied with the results of the exercise. The code is not being considered for the base system for three reasons:

• The code has issues that need more work.
• clang didn't really implement support for FORTIFY_SOURCE and the GCC model doesn't really work well with clang. Note that Google's Bionic libc has a new design that works with clang.
• FORTIFY_SOURCE can be largely replaced by combining other technologies like static checkers and sanitizers that don't add code to the C library. The “strong” stack protection and safe stack have also improved significantly making FORTIFY_SOURCE redundant.