C-Based Toolchain Hardening Cheat Sheet - Revision history

Dominique RIGHETTO: Point to the official site

2019-07-15T13:59:26Z

Point to the official site

Thunder-Son: Migration to GitHub

2019-02-13T08:55:30Z

Migration to GitHub

Show changes

Jmanico: Reptoline fix to address speculative execution CPU vulnerabilities such as Spectre and Meltdown

2018-03-23T02:31:59Z

Reptoline fix to address speculative execution CPU vulnerabilities such as Spectre and Meltdown

Jmanico: /* Other Cheatsheets */

2017-09-11T06:00:09Z

‎Other Cheatsheets

Jmanico: /* Authors and Editors */

2017-09-11T05:59:58Z

‎Authors and Editors

Jmanico: moving nav to bottom for mobile friendliness

2015-07-18T23:10:40Z

moving nav to bottom for mobile friendliness

Jmanico at 03:10, 8 April 2014

2014-04-08T03:10:59Z

Jmanico at 03:10, 8 April 2014

2014-04-08T03:10:38Z

Jmanico at 11:59, 20 March 2014

2014-03-20T11:59:29Z

Damien Azambourg: Fixing couple of mistypes

2013-12-28T01:51:18Z

Fixing couple of mistypes

← Older revision		Revision as of 13:59, 15 July 2019
Line 4:		Line 4:
	The Cheat Sheet Series project has been moved to [https://github.com/OWASP/CheatSheetSeries GitHub]!		The Cheat Sheet Series project has been moved to [https://github.com/OWASP/CheatSheetSeries GitHub]!

−	Please visit [https://~~github~~.~~com/OWASP/CheatSheetSeries/blob/master~~/cheatsheets/C-~~Based_Toolchain_Hardening_Cheat_Sheet~~.md C-Based Toolchain Hardening Cheat Sheet] to see the latest version of the cheat sheet.	+	Please visit [https://cheatsheetseries.owasp.org/cheatsheets/C-Based_Toolchain_Hardening.html C-Based Toolchain Hardening Cheat Sheet] to see the latest version of the cheat sheet.

@@ Line 49: / Line 49: @@
 A release configuration should also use <tt>-O2</tt>/<tt>-O3</tt>/<tt>-Os</tt> and <tt>-g1</tt>/<tt>-g2</tt>. The optimizations will make it somewhat more difficult to make sense of a stack trace, but they should be few and far between. The <tt>-g''N''</tt> flag ensures debugging information is available for post mortem analysis. While you generate debugging information for release builds, you should strip the information before shipping and check the symbols into you version control system along with the tagged build.
 <tt>NDEBUG</tt> will also remove asserts from your program by defining them to <tt>void</tt> since its not acceptable to crash via <tt>abort</tt> in production. You should not depend upon assert for crash report generation because those reports could contain sensitive information and may end up on foreign systems, including for example, [http://msdn.microsoft.com/en-us/library/windows/hardware/gg487440.aspx Windows Error Reporting]. If you want a crash dump, you should generate it yourself in a controlled manner while ensuring no sensitive information is written or leaked.
@@ Line 56: / Line 58: @@
 === Test Builds ===
-A Test build is closely related to a release build. In this build configuration, you want to be as close to production as possible, so you should be using <tt>-O2</tt>/<tt>-O3</tt>/<tt>-Os</tt> and <tt>-g1</tt>/<tt>-g2</tt>. You will run your suite of ''positive'' and ''negative'' tests against the test build.
+A Test build is closely related to a release build. In this build configuration, you want to be as close to production as possible, so you should be using <tt>-O2</tt>/<tt>-O3</tt>/<tt>-Os</tt> <tt>-g1</tt>/<tt>-g2</tt> and "Reptoline" configuration options. You will run your suite of ''positive'' and ''negative'' tests against the test build.
 You will also want to exercise all functions or methods provided by the program and not just the public interfaces, so everything should be made public. For example, all member functions public (C++ classes), all selectors (Objective C), all methods (Java), and all interfaces (library or shared object) should be made available for testing. As such, you should:

@@ Line 107: / Line 107: @@
 * Kevin Wall - kevin, owasp.org
-== Other Cheatsheets ==
+= Other Cheatsheets =
 {{Cheatsheet_Navigation_Body}}

@@ Line 101: / Line 101: @@
 For additional details on the GCC and Windows options and flags, see ''[http://gcc.gnu.org/onlinedocs/gcc/Option-Summary.html GCC Options Summary]'' and ''[http://msdn.microsoft.com/en-us/magazine/cc337897.aspx Protecting Your Code with Visual C++ Defenses]''.
-== Authors and Editors ==
+= Authors and Editors =
 * Jeffrey Walton - jeffrey, owasp.org

@@ Line 106: / Line 106: @@
 * Jim Manico - jim, owasp.org
 * Kevin Wall - kevin, owasp.org
 == Other Cheatsheets ==

@@ Line 1: / Line 1: @@
   __NOTOC__
-<div style="width:100%;height:160px;border:0,margin:0;overflow: hidden;">[[File:OWASP_Project_Header.jpg|link=]]</div>
+<div style="width:100%;height:160px;border:0,margin:0;overflow: hidden;">[[File:Cheatsheets-header.jpg|link=]]</div>
 {| style="padding: 0;margin:0;margin-top:10px;text-align:left;" |-

@@ Line 4: / Line 4: @@
 {| style="padding: 0;margin:0;margin-top:10px;text-align:left;" |-
 | valign="top"  style="border-right: 1px dotted gray;padding-right:25px;" |
-= Introduction =
+Last revision (mm/dd/yy): '''{{REVISIONMONTH}}/{{REVISIONDAY}}/{{REVISIONYEAR}}'''
 [[C-Based Toolchain Hardening Cheat Sheet]] is a brief treatment of project settings that will help you deliver reliable and secure code when using C, C++ and Objective C languages in a number of development environments. A more in-depth treatment of this topic can be found [https://www.owasp.org/index.php/C-Based_Toolchain_Hardening here]. This cheatsheet will guide you through the steps you should take to create executables with firmer defensive postures and increased integration with the available platform security. Effectively configuring the toolchain also means your project will enjoy a number of benefits during development, including enhanced warnings and static analysis, and self-debugging code.

@@ Line 1: / Line 1: @@
 [[C-Based Toolchain Hardening Cheat Sheet]] is a brief treatment of project settings that will help you deliver reliable and secure code when using C, C++ and Objective C languages in a number of development environments. A more in-depth treatment of this topic can be found [https://www.owasp.org/index.php/C-Based_Toolchain_Hardening here]. This cheatsheet will guide you through the steps you should take to create executables with firmer defensive postures and increased integration with the available platform security. Effectively configuring the toolchain also means your project will enjoy a number of benefits during development, including enhanced warnings and static analysis, and self-debugging code.
-There are four areas to be examined when hardening the toolchain: configuration, integration, static analysis, and platform security. Nearly all areas are overlooked or neglected when setting up a project. The neglect appears to be pandemic, and it applies to nearly all projects including Auto-configured projects, Makefile-based, Eclipse-based, and Xcode-based. Its important to address the gaps at configuration and build time because its difficult to impossible to [http://sourceware.org/ml/binutils/2012-03/msg00309.html add hardening on a distributed executable after the fact] on some platforms.
+There are four areas to be examined when hardening the toolchain: configuration, integration, static analysis, and platform security. Nearly all areas are overlooked or neglected when setting up a project. The neglect appears to be pandemic, and it applies to nearly all projects including Auto-configured projects, Makefile-based, Eclipse-based, and Xcode-based. It's important to address the gaps at configuration and build time because it's difficult to impossible to [http://sourceware.org/ml/binutils/2012-03/msg00309.html add hardening on a distributed executable after the fact] on some platforms.
 For those who would like a deeper treatment of the subject matter, please visit [[C-Based_Toolchain_Hardening|C-Based Toolchain Hardening]].
@@ Line 22: / Line 22: @@
 You should support three build configurations. First is ''Debug'', second is ''Release'', and third is ''Test''. One size does '''not''' fit all, and each speaks to a different facet of the engineering process. You will use a debug build while developing, your continuous integration or build server will use test configurations, and you will ship release builds.
-'s K&R code and one size fits all flags are from a bygone era. Proccesses have evolved and matured to meet the challanges of a modern landscape, including threats. Because tools like Autconfig and Automake [https://lists.gnu.org/archive/html/automake/2012-12/msg00019.html do not support the notion of build configurations], you should prefer to work in an Integrated Develop Environments (IDE) or write your makefiles so the desired targets are supported. In addition, Autconfig and Automake often ignores user supplied flags (it depends on the folks writing the various scripts and templates), so you might find it easier to again write a makefile from scratch rather than retrofitting existing auto tool files.
+'s K&R code and one size fits all flags are from a bygone era. Processes have evolved and matured to meet the challenges of a modern landscape, including threats. Because tools like Autconfig and Automake [https://lists.gnu.org/archive/html/automake/2012-12/msg00019.html do not support the notion of build configurations], you should prefer to work in an Integrated Develop Environments (IDE) or write your makefiles so the desired targets are supported. In addition, Autconfig and Automake often ignore user supplied flags (it depends on the folks writing the various scripts and templates), so you might find it easier to again write a makefile from scratch rather than retrofitting existing auto tool files.
 === Debug Builds ===