Compartilhar via

Security tools will not make your software secure...

  • Artigo

Be sure to read Howard's article, and pay attention to this section. Here's an excerpt from Michael's" A Look Inside the Security Development Lifecycle at Microsoft"....

//======================================//

Security tools will not make your software secure. They will help, but tools alone do not make code resilient to attack. There is simply no replacement for having a knowledgeable work force that will use the tools to enforce policy. The new version of Visual Studio® 2005 Team System Developer's Edition includes some very, very useful security tools:

PREfast PREfast is a static analysis tool for C/C++ code. It can find some pretty subtle security defects, and some egregious bugs, too. This is lint on security steroids.

Standard Annotation Language (SAL) Of all the tools we have added to Visual Studio 2005, this is the technology that excites me the most because it can help find some hard to spot bugs. Imagine you have a function like this:

Copy Code

 void *function(
    char *buffer, 
    DWORD cbBufferLength);

You know that buffer and dwBufferLength are tied at the hip; buffer is cbBufferLength bytes long. But the compiler does not know that—all it sees is a pointer and a 32-bit unsigned integer. Using SAL, you can link the two. So the header that includes this function prototype might look like the following:

Copy Code

 void *function(
    _in_bytecount(cbBufferLength) char *buffer, 
    DWORD cbBufferLength);

Please note the final syntax used for SAL may change before Visual Studio 2005 ships.

FxCop You may already know of FxCop—it's a tool to find defects, including security defects in managed code. It's available as a download from www.gotdotnet.com, but the version in Visual Studio 2005 is fully integrated, and includes some new issues to watch out for.

Application Verifier AppVerifier is a runtime tool that operates on a running application. It can be used to trap memory-related issues at run time, including heap-based buffer overruns.

Other tools and requirement at Microsoft include:

  • All unmanaged C/C++ code must be compiled with the /GS stack overrun detection capability.
  • All unmanaged C/C++ code must be linked using the /SafeSEH option.
  • All RPC code must be compiled with the MIDL /robust flag.
  • Security issues flagged by FxCop and PREfast must be fixed.
  • The functions shown in Figure 4 are banned for new code, and should be removed over time for legacy code.

Figure 4 Sample Banned Functions

Banned API

Strsafe Replacement

Safe C and C++ Libraries

strcpy, wcscpy, _tcscpy, _mbscpy, lstrcpy, lstrcpyA, lstrcpyW, strcpyA, strcpyW

String*Copy or String*CopyEx

strcpy_s

strcat, wcscat

String*Cat or String*CatEx

strcat_s

wnsprintf, wnsprintfA, wnsprintfW

String*Printf or String*PrintfEx

sprintf_s

_snwprintf, _snprintf

String*Printf or String*PrintfEx

_snprintf_s or _snwprintf_s

wvsprintf, wvsprintfA, wvsprintfW, vsprintf

String*VPrintf or String*VPrintfEx

_vstprintf_s

_vsnprintf, _vsnwprintf

String*VPrintf or String*VPrintfEx

vsntprintf_s

strncpy, wcsncpy

String*CopyN or String*CopyNEx

strncpy_s

strncat, wcsncat

String*CatN or String*CatNEx

strncat_s

scanf, wscanf

None

sscanf_s

strlen, wcslen, _mbslen, _mbstrlen

String*Length

strlen_s

You can read about the Strsafe string replacement code in "Strsafe.h: Safer String Handling in C". The Safe C library is the new C runtime library replacement built into Visual Studio 2005. You can read about it at "Safe! Repel Attacks on Your Code with the Visual Studio 2005 Safe C and C++ Libraries".

//======================================//

Comments