MSDN Magazine - November 2008 - (Page 46)

Test Your Security IQ Michael Howard and Bryan Sullivan Both of us enjoy reviewing code for security bugs. We would even go as far as to say we’re pretty good at it. We don’t pretend we’re the best, but we can generally find plenty of bugs pretty quickly. Can you? Would you know a security bug if you saw one? Find out by taking this quiz. Each code sample has at least one security vulnerability. Try to spot the bugs and see how you rate. Following the code is a summary of any vulnerabilities, some commentary, and, where appropriate, how the Security Development Lifecycle (SDL) can help find these bugs. Thanks to Peter Torr and Eric Lippert for providing input and code samples. Bug #1 (C or C++) void func(char *s1, char *s2) { char d[32]; strncpy(d,s1,sizeof d - 1); strncat(d,s2,sizeof d - 1); } Bug #2 (C or C++) int main(int argc, char* argv[]) { char d[32]; if (argc==2) strcpy(d,argv[1]); return 0; Answer } We thought we’d start off pretty easy on you with a good ol’ buffer overrun. To many people, the code is fine and secure because the code uses the bounded strncpy and strncat functions. However, these functions are only secure if the buffer sizes are correct, and in this example the buffer sizes are wrong. Dead wrong. Technically, the first call is secure, but the second call is wrong. The last argument of the strncpy and strncat functions is the amount of space left in the buffer, and you just exhausted some or all of that space with the call to strncpy. Buffer overflow. Michael blogged about this exact bug type in 2004 (see blogs.msdn.com/michael_howard/ archive/2004/10/29/249713.aspx). Answer In Visual C++ 2005 and later, warning C4996 tells you to replace the bad function call with a safer call, and the /analyze option would issue a C6053 warning indicating that strncat might not zero terminate the string. To be perfectly honest, strncpy and strncat (and their “n” cousins) are worse than strcpy and strcat (and their ilk) for a couple of reasons. First, the return value is just silly—it’s a pointer to a buffer, a buffer that might be valid or might not. You have no way of knowing! Second, it’s really tough to get the destination buffer size right. If you spotted the bug, give yourself one point. 46 msdn magazine This is an evil bug. We have seen this bug used so many times as an example of a buffer overrun, and most of the time it’s impossible to determine if there is a security bug in the code or not. It all depends on how the code is used. If this is a standard Win32 EXE, then there is no security bug here because the worst you can do is attack yourself and run code as yourself, which isn’t a security bug. Now, if this code were located in ServiceMain of a Windows service running as SYSTEM, for e xample, or the main function of a Linux application setuid root, then the code becomes a bona fide security bug. Let’s say the code is a Linux application marked setuid root. When the application is started by a normal user, the application actually runs as root, which means this is a local privilege elevation vulnerability. As in the code example given in Bug #1, C4996 warnings are issued for the call to strcpy, and /analyze would issue a C6204 indicating a potential buffer overrun. If you answered, “Huh! I need much more context,” then give yourself two points; otherwise, no points for you. http://blogs.msdn.com/michael_howard/archive/2004/10/29/249713.aspx http://blogs.msdn.com/michael_howard/archive/2004/10/29/249713.aspx

Table of Contents Feed for the Digital Edition of MSDN Magazine - November 2008

Contents MSDN Magazine - November 2008 Toolbox CLR Inside Out Data Points Cutting Edge Security Briefs Test Your Security IQ Agile SDL Access Control Utility Spotlight RIA Test Run Wicked Code Foundations Team System End Bracket

MSDN Magazine - November 2008

For optimal viewing of this digital publication, please enable JavaScript and then refresh the page. If you would like to try to load the digital publication without using Flash Player detection, please click here.