Secure Programming with GCC and GLibc - CanSecWest

Secure Programmingwith GCC and GLibcMarcel HoltmannCanSecWest 2008, Vancouver

Introduction●●Working for the Open Source TechnologyCenter at IntelUsed to work for the Red Hat SecurityResponse Team● Have been to CanSecWest once or twice ;­)Secure Programming with GCC and GLibc 2

Agenda●●●Secure programming in generalWelcome to 21stcenturyTips and tricksSecure Programming with GCC and GLibc 3

Secure programming●●●●●Understand the limits and flaws of yourprogramming languageUnderstand your own codeExpect the unexpectedDo code reviewsListen to your compilerSecure Programming with GCC and GLibc 4

Programming languages●●●C and C++ are not secure languagesGo for Java, C# or similar languagesBut ask yourself which language has been usedto write JVM for example●There is always a weakest linkSecure Programming with GCC and GLibc 5

Something to keep in mind●●You have to know what you are doingProgramming is art●●Nothing I gonna tell you in the next 30 minutesis going to change thisHowever it might make your life easierSecure Programming with GCC and GLibc 6

The threats●●●●●●Format string attacksBuffer overflowsHeap overflows and double freeStack overwritesELF section overwritesFixed address space layoutSecure Programming with GCC and GLibc 7

The protection●●●The Linux kernel (if you use Linux)GCC compile time optionsGLibc runtime options●And of course the developerSecure Programming with GCC and GLibc 8

Linux kernel options●Address space layout randomization (ASLR)● mmap, Stack, vDSO as of 2.6.18● Heap/executable as of 2.6.24●●●Requirement for ­pieExecShield●NX emulation (Red Hat and Fedora only)Stack ProtectorSecure Programming with GCC and GLibc 9

GCC options●●●gcc ­fstack­protectorld ­z relrold ­pie / gcc ­fPIE● gcc ­D_FORTIFY_SOURCE=2 ­O2●gcc ­Wformat ­Wformat­securitySecure Programming with GCC and GLibc 10

GLibc options●●●Heap protectionDouble free checkingPointer encryption●Enabled by defaultSecure Programming with GCC and GLibc 11

Distributions●●●●Every major Linux distribution will try to enablemost of these “security” featuresSome patch the default options of GCCNormally they never contribute back to theupstream projectHave options for these features and make thedistributions use themSecure Programming with GCC and GLibc 12

Format strings●●●­Wformat●●Check format types and conversationsSafe to use and part of ­Wall­Wformat­security●●Check potential security risks within printf and scanfNon string literals or missing format argumentsListen to compiler warningsSecure Programming with GCC and GLibc 13

Buffer checks● ­D_FORTIFY_SOURCE=2 ­O2●●During compilation most buffer length are knownInclude compile time checks and also runtime checks● The source must be compiled with ­O2●●●Format strings in writable memory with %n are blockedNo negative impact has been reportedUsage in upstream projects is almost zeroSecure Programming with GCC and GLibc 14

Heap protection●●GLibc includes heap protectionDouble free attempts will be detected●●Always enabled when using GLibcNo negative impact knownSecure Programming with GCC and GLibc 15

Stack protection●●●Mainline GCC featureAlso known as stack smashing protection orstack canariesMissing support for ia64 and alpha systems● Helps to reduce stack overflows, but a 100%protection can not be expectedSecure Programming with GCC and GLibc 16

Randomization●●●●Position Independent Executable (PIE)Requires ASLR support in the kernelGCC and linker option (­fPIE and ­pie)Doesn't work on hppa and m68k systems●Randomization is limited and only good forprotecting against remote vulnerabilitiesSecure Programming with GCC and GLibc 17

Pointer encryption●●●●Protection of pointer in writable memoryIt is hard, but in theory the randomization canbe overcomeStore only mangled function pointer and XORwith a random numberEncryption is considered faster than canariesand as secureSecure Programming with GCC and GLibc 18

ELF protection●●●●Linker option (­z relro)Mark various ELF memory sections read­onlybefore handing over the program executionAlso known as ELF hardening or protectionagainst GOT overwrite attacksNo problem reported so farSecure Programming with GCC and GLibc 19

Red Hat and Fedora securitySecure Programming with GCC and GLibc 20

Debian and Ubuntu security●●Install the Hardening wrapper●apt­get install hardening­wrapperSet an environment variable to activate it●●export DEB_BUILD_HARDENING=1export DEB_BUILD_HARDENING_[feature]=0●Ubuntu has stack protector by defaultSecure Programming with GCC and GLibc 21

A trivial example#include #include #include #include #include #include #include int main(int argc, char *argv[]){char buf[16];if (argc > 1) {strcpy(buf, argv[1]);printf("Your first argument was: ");printf(buf);printf("\n");} else {fprintf(stderr, "Usage: %s ARG\n", argv[0]);exit(1);}}return 0;Secure Programming with GCC and GLibc 22

Using the wrapper# DEB_BUILD_HARDENING=1 make trivialcc trivial.c ­o trivialtrivial.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 terminatedSegmentation fault (core dumped)Secure Programming with GCC and GLibc 23

Other useful tools●●●Statical analysisThe Linux kernel sparse●●User/kernel pointer checksEndian conversion checksThe memory checker valgrind●Listen to its warningsSecure Programming with GCC and GLibc 24

Conclusion●●Use the security features that are available andmake them mandatoryListen to your compiler and understand thewarnings – fix the cause, not the warning●You still have to write good and secure code,but listen to your tools when they try to tell yousomething ...Secure Programming with GCC and GLibc 25

Thanks for your attentionmarcel@holtmann.org