I'm doing a course in college, where one of the labs is to perform buffer overflow exploits on code they give us. This ranges from simple exploits like changing the return address for a function on a stack to return to a different function, all the way up to code that changes a programs register/memory state but then returns to the function that you called, meaning that the function you called is completely oblivious to the exploit.
I did some research into this, and these kinds of exploits are used pretty much everywhere even now, in things like running homebrew on the Wii, and the untethered jailbreak for iOS 4.3.1
My question is why is this problem so difficult to fix? It's obvious this is one major exploit used to hack hundreds of things, but seems like it would be pretty easy to fix by simply
truncating any input past the allowed length, and simply sanitizing all input that you take.
EDIT: Another perspective that I'd like answers to consider – why do the creators of C not fix these issues by reimplementing the libraries?
Best Answer
They did fix the libraries.
Any modern C standard library contains safer variants of
strcpy,strcat,sprintf, and so on.On C99 systems - which is most Unixes - you will find these with names like
strncatandsnprintf, the "n" indicating that it takes an argument that's the size of a buffer or a maximum number of elements to copy.These functions can be used to handle many operations more securely, but in retrospect their usability is not great. For example some
snprintfimplementations don't guarantee the buffer is null-terminated.strncattakes a number of elements to copy, but many people mistakenly pass the size of the dest buffer.On Windows, one often finds the
strcat_s,sprintf_s, the "_s" suffix indicating "safe". These too have found their way into the C standard library in C11, and provide more control over what happens in the event of an overflow (truncation vs. assert for example).Many vendors provide even more non-standard alternatives like
asprintfin the GNU libc, which will allocate a buffer of the appropriate size automatically.The idea that you can "just fix C" is a misunderstanding. Fixing C is not the problem - and has already been done. The problem is fixing decades of C code written by ignorant, tired, or hurried programmers, or code that has been ported from contexts where security didn't matter to contexts where security does. No changes to the standard library can fix this code, although migration to newer compilers and standard libraries can often help identify the problems automatically.