MSDN Magazine - November 2008 - (Page 42)

• Authentication and authorization Code Review and Fuzz Testing Priority • Process name and process identity Think about this for a moment; you have a lot of code to re• Comments (if needed) view and test. But you cannot spend every waking moment for Figure 1 shows a few examples. Clearly, the first network port the next 10 years reviewing code because, at some point, you have is the most exposed because it is exposed to anyone on the planet. to ship a product to customers. What this means is that you must The most exposed entry points are the entry points at greatest risk prioritize your security efforts; therefore, you must give the riskiof attack because something that is remotely accessible can be ac- est components your first and deepest efforts (I recommend that cessed by anyone with a computer on the same network—in this you read the “Who Is the Bad Guy” sidebar for some tips on findcase, probably the Internet. Something that is accessible by anon- ing the riskiest components). This means reviewing and fuzzing ymous users is accessible by anyone with no authentication or au- the riskiest code first. thorization. So an entry point that is accessible anonymously and When reviewing code by hand, it is important to review the remotely can be accessed by absolutely anyone, and that includes most exposed code first. For example, the TCP/1234 socket examan awful lot of bad guys. ple might have code like that shown in Figure 2. Because the call The administrative named pipe is accessible only to remote (and to recv reads from an unauthenticated and remote network port, local) administrators, which is correctly enforced using an ACL. buf should be treated as toxic waste until it is verified. In security It’s important that you verify the ACLs on all Windows named ob- circles, this data is often considered tainted and should not be rejects, including named pipes. lied upon for any accuracy or structure. You will also notice that many entry points are located in code To make things a little easier during code review, create a table running as SYSTEM. The combination of an unauthenticated, re- that includes the source code location and API call for the entry motely accessible entry point and a process running as SYSTEM is point as well as the data (see Figure 3). Now follow the data from the largest possible exposure you can have in Windows. If there is the entry point API to the code that verifies or sanitizes the incoma security bug in this code, anyone can make it fail from anywhere ing data. If you have no code that verifies the data integrity and your on the planet. And exploited code would run as SYSTEM, mean- code performs potentially dangerous operations on the incoming ing the exploit has total control of the computer. I’ll cover more of data, then you might have a coding bug at best and a severe vulnerthis topic later in the column. ability at worst. Regardless of the code behavior, you should never The degree of exposure helps drive code review and fuzz testing assume the data is well formed. priority. That’s discussed next. Figure 2 A Potential Problem Buffer SOCKET remoteSocket = accept(listenSocket,NULL, NULL); if (remoteSocket == INVALID_SOCKET) { PRINTERROR(“accept()”); closesocket(listenSocket); return; } // Receive data from the client char szBuf[256]; memset(buf, 0, sizeof(buf)); nRet = recv(remoteSocket, buf, // Danger! sizeof(buf), 0); if (nRet == INVALID_SOCKET) { PRINTERROR(“recv()”); closesocket(listenSocket); closesocket(remoteSocket); return; } // process data in buf Look back at that last line: “never assume the data is well formed.” The goal of fuzz testing is to determine whether you do make assumptions and, if so, whether someone can cause your application to fail by violating those assumptions. I am not going to explain fuzz testing here because it has been covered numerous times in MSDN Magazine (for instance, see the article “Fuzz Testing: Create a Custom Test Interface Provider for Team System” by Dan Griffin at msdn.microsoft.com/magazine/cc163313.aspx), but I will take a look at how you could be using fuzz testing. Just like code review, you cannot fuzz test every possible code path, so you need to prioritize by exposure. Therefore, you should fuzz the most exposed entry points first. In my little example, I would fuzz test the TCP/1234 entry point brutally, early, and often. In fact, I would never stop fuzzing that entry point! CPU time is pretty cheap, after all. I would go one step further and ask myself, why is this interface so highly exposed? Can I reduce the exposure by default? And that is the art of attack surface reduction. Fuzz Testing Figure 3 Analyzing Entry Points Entry Point TCP/1234 \\.\pipe\admin ncacn_ip_tcp 609b954b-4fb6-11d1-9971-00c04fbbb345 Config.xml 42 msdn magazine Source File Readfromsocket.cpp AdminConsole.cpp UserInfo_i.c and UserInfo.idl Config.cpp API and Data recv(,buf,) ReadFile(,bCommand) Various ReadFile(,bFileContents) Security Briefs http://msdn.microsoft.com/magazine/cc163313.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.