{"id":16275,"date":"2017-06-28T07:18:23","date_gmt":"2017-06-28T14:18:23","guid":{"rendered":"https:\/\/blogs.msdn.microsoft.com\/vcblog\/?p=16275"},"modified":"2019-02-18T17:48:25","modified_gmt":"2019-02-18T17:48:25","slug":"security-features-in-microsoft-visual-c","status":"publish","type":"post","link":"https:\/\/devblogs.microsoft.com\/cppblog\/security-features-in-microsoft-visual-c\/","title":{"rendered":"Security Features in MSVC"},"content":{"rendered":"

Shareable link: https:\/\/aka.ms\/msvcsecurity<\/a>\n\u70b9\u8fd9\u91cc\u770b\u4e2d\u6587\u7248<\/a><\/p>\n

Every developer makes mistakes. No matter how careful you are when writing code, you will introduce bugs. And any bug can become a security vulnerability when software that runs in a connected environment or is used long past its initially planned lifespan. Code that isn’t correct is insecure code.<\/p>\n

The Microsoft Visual C++ toolset offers numerous features that help you write secure, correct code from before you start typing code until after you\u2019ve shipped it to your users.<\/p>\n

For more information on specific security features in the MSVC toolset, make sure you review Security Best Practices for C++<\/a>.<\/p>\n

Before you write any code<\/h3>\n

Secure code starts before you write your first line of code. The compiler toolset can\u2019t show you design defects that might lead to security exploits, but there are many resources in print and online that will help you think about potential exploits and how to design your code securely. For example, almost everyone who\u2019s been at Microsoft for a while has read Michael Howard and David LeBlanc’s Writing Secure Code<\/a>.<\/p>\n

When you start writing code it\u2019s important that you use modern C++ constructs to manage and access resources. One of the best resources available is the C++ Core Guidelines<\/a>, a set of tried-and-true guidelines, rules, and best practices about coding in C++. Coding practices recommended in the C++ Core Guidelines help you write simpler, more modern, software. In doing so, you’ll avoid common pitfalls such as integer overflow or buffer overruns, making your code more secure. And many of the C++ Core Guidelines are enforceable with a static analysis code tool that\u2019s included with Visual C++<\/a>.<\/p>\n

When you’re writing code<\/h3>\n

What can you do to help yourself when you’re writing code? First, get all the value you can from built-in compiler diagnostics by setting your warning levels properly. Run code analysis after you build to let the compiler toolset dive into a deeper analysis of your code. And don\u2019t forget to do regular code reviews with your team<\/a>!<\/p>\n

Compiler Warnings<\/h4>\n

One of the most frequently-used security features is compiler warnings. The MSVC compiler provides many switches that allow you to control which warnings you will see in your code and whether they are kept as informational messages or cause your compile to fail.<\/p>\n

Some compiler warnings are kept off-by-default<\/a> because they are emitted too frequently in legacy code and most users don\u2019t want to see them. But many of these warnings indicate real bugs in your program. For example, your code may have a valid reason to compare an unsigned value to a negative number<\/a> but it could also be a bug. By enabling the off-by-default warnings you can catch potential errors.<\/p>\n

To learn more about how you can adjust build settings to allow the compiler to find as many bugs in your code as possible, see the documentation on the compiler options warning level<\/a>.<\/p>\n

<\/a><\/p>\n

Static Code Analysis Security Features<\/h4>\n

We write frequently about C++ Code Analysis on this blog. We also keep you updated about the CppCoreCheck extension that checks your code for rules derived from the C++ Core Guidelines. But did you know that Microsoft has long considered PREfast, the engine at the core of our Code Analysis, a security tool? The tool was originally developed by a team that focused on software excellence and was later owned by the Secure Development Lifecycle team before making its way to the C++ team to be included with all versions of Visual Studio.<\/p>\n

We now have a number of Code Analysis tools built upon the PREfast engine, including our base set of \/analyze rules<\/a>, the ESPC Concurrency Checker<\/a> (pdf) and the CppCoreCheckers<\/a>. We are also looking for ways to help you integrate Code Analysis more deeply into your daily development routine<\/a>.<\/p>\n

As the name implies, code analysis does a deeper analysis of your code to find possible errors. While compiler detects many potential errors in your code, code analysis looks through an entire function to determine whether there are some code paths that could result in an error. We call this kind of analysis a \u201cpath-sensitive\u201d analysis.<\/p>\n

While the compiler can do a lot of path-sensitive analysis, there are many cases it can\u2019t identify. For example, compiling this code with all compiler warnings turned on (\/Wall<\/a><\/code>) and analysis (\/analyze<\/a><\/code>) shows that the compiler can only find one of three potential bugs:<\/p>\n

\nvoid one()\n{\n    int a[4];\n    a[4] = 1; \/\/ Buffer overrun, stack overflow\n}\n\nvoid two(int *p)\n{\n   bool isnull = false;\n   if (p == nullptr)\n      isnull = true;\n   *p = 1;   \/\/ Null pointer dereference\n}\n\nint three(bool b)  \n{  \n   int i;  \n   if (b)  \n      i = 0;  \n   return i; \/\/ i is unintialized if b is false  \n}\n<\/pre>\n
\nC:\\tmp>cl \/c example.cpp \/Wall \/analyze\nMicrosoft (R) C\/C++ Optimizing Compiler Version 19.10.25019 for x64\nCopyright (C) Microsoft Corporation.  All rights reserved.\n\nexample.cpp\nc:\\tmp\\example.cpp(4) : warning C6201: Index '4' is out of valid index range '0' to '3' for possibly stack allocated buffer 'a'.\nc:\\tmp\\example.cpp(4) : warning C6386: Buffer overrun while writing to 'a':  the writable size is '16' bytes, but '20' bytes might be written.: Lines: 3, 4\nc:\\tmp\\example.cpp(12) : warning C6011: Dereferencing NULL pointer 'p'. : Lines: 9, 10, 11, 12\nc:\\tmp\\example.cpp(22) : warning C6001: Using uninitialized memory 'i'.: Lines: 17, 18, 22\nc:\\tmp\\example.cpp(4) : warning C4789: buffer 'a' of size 16 bytes will be overrun; 4 bytes will be written starting at offset 16\nc:\\tmp\\example.cpp(22) : warning C4701: potentially uninitialized local variable 'i' used\n<\/pre>\n
There’s an error in each function in the source above. The compiler misses one of these three errors and indirectly attributes another. As the parse information available to the compiler improves<\/a>, the analysis in the compiler will improve and you’ll see more instances where diagnostics can be duplicated between tools.<\/p>\n
    \n
  1. In function one<\/code> code analysis tells us that we’re using the bounds of the array as an index, causing C6201<\/a>. Both code analysis and the compiler pick up on the memory corruption, the former emitting C6386<\/a>, the latter, C4789<\/a>.<\/li>\n
  2. In function two<\/code> we dereference of a null pointer on one code path, causing C6011<\/a>. The compiler misses this error entirely.<\/li>\n
  3. The compiler and code analysis both pick up on the error in function three<\/code>. The compiler issues off-by-default warning C4701<\/a>; code analysis, C6001<\/a>.<\/li>\n<\/ol>\n
    Code analysis also excels at finding code that doesn\u2019t do what you may think it does. For example, warning C6268 finds code that contains an incorrect order of operations and suggests using parentheses to make the order clear. The example given in the documentation<\/a> contains a potential buffer overrun.<\/p>\n
    You can read more about using C++ Code Analysis both inside VS and from the command line<\/a> on the Microsoft Docs site.<\/p>\n
    Code Reviews<\/h4>\n
    Code reviews can seem like a lot of overhead but they save time in the long run. Some teams do one-on-one code reviews, others send out all changes to a group of reviews, some bring the team together every Friday to look over all the week\u2019s changes. It doesn\u2019t matter how you do code reviews. They will turn out to be one of the most valuable techniques you can use to improve the quality of your code. Find a process that works for your team and use it.<\/p>\n
    Additional Security Checks<\/h4>\n
    The \/sdl compiler switch<\/a> enables additional warnings focused on security issues as defined by the Microsoft Secure Development Lifecycle<\/a> process. The \/sdl switch is in many ways an expansion of off-by-default warning C4701<\/a> and is thus off by default.<\/p>\n
    CRT Secure Function Overloads<\/h4>\n
    Security wasn’t an important design point for the C library\u2014normally code was written and run inside of an organization instead of being exposed to a worldwide network of computers. The C “string” has no metadata associated with it that records its length. For example, functions that deal with strings, such as strcpy<\/code>, must assume that the buffers supplied as parameters are an appropriate size for the requested operation. Several memory operations have similar limitations.<\/p>\n
    Over ten years ago Microsoft introduced a set of overloads to these functions that validate their parameters for security<\/a>. If you are still using C-style functions you should consider moving to C++, which offers more safety in its objects and abstractions. If you can’t use C++, at least use the secure versions of the C runtime functions<\/a>.<\/p>\n
    (NB: When we introduced this feature we incorrectly called the insecure C functions “deprecated”. This only means that Microsoft does not recommend use of the insecure functions, instead recommending you use the secure overloads. We’re aware that the term “deprecated” was used incorrectly.)<\/p>\n
    When you\u2019re testing your code<\/h3>\n
    The compiler toolset offers many options that help you when you\u2019re testing your code. Most of these switches aren\u2019t intended to be shipped with your final, retail builds of your program. They\u2019re turned on for debug builds\u2014either by default or opt-in\u2014so that you can find more bugs during your testing.<\/p>\n
    CRT Debug Heap<\/h4>\n
    The CRT Debug Heap is enabled when you compile your program in debug (non-release) mode. It finds common heap memory errors, including buffer overruns and leaks. The CRT Debug Heap will assert when it encounters any heap memory errors as you test your code. Various debug routines<\/a> are enabled when you define the _DEBUG<\/code> flag.<\/p>\n
    Runtime Checks<\/h4>\n
    The CRT provides Runtime Checks<\/a> enabled through use of the \/RTC<\/code> switch. These checks find real logic errors in your program such as data loss, initialization issues, and stack frame checking. Runtime Checks are only intended for when you are active testing your debug builds and are incompatible with optimizations. Because of these limitations they are off by default.<\/p>\n
    Checked Iterators<\/h4>\n
    Checked iterators help ensure that your code doesn\u2019t accidentally overwrite the bounds of iterable containers in your code. They can be used both in debug code<\/a> (as debug iterators) and in release code<\/a> (as checked iterators.)<\/p>\n
    After your code is compiled<\/h3>\n
    The Windows team provides tools that help validate that your compiled binaries are secure. You can find these tools in the Debugging Tools for Windows<\/a> and the Windows SDK<\/a>.<\/p>\n
    GFlags and PageHeap<\/h4>\n
    The GFlags and PageHeap tools<\/a> enable heap allocation monitoring for Windows. When using these tools, Windows will reserve memory at the boundary of every allocation that allows it to detect memory accesses outside of the allocated memory.<\/p>\n
    Application Verifier<\/h4>\n
    Application Verifier<\/a> is a dynamic verification tool that subjects your binary to a number of stresses and tests as you exercise the code and generates a report of potential vulnerabilities.<\/p>\n
    Runtime protection for released code<\/h3>\n
    The MSVC code generator and linker provide several security features that continue to offer protection long after you\u2019ve built and deployed your code. Because the code generator can see all of your code at once–as opposed to just one source file at a time–it can often detect errors and vulnerabilities that can\u2019t be found in an individual source file. And the code generator and linker work with the OS loader and runtime to provide even more security when your binary is loaded and executed in Windows.<\/p>\n
    Buffer Security Check<\/h4>\n
    One of the oldest security features in the code generator is the Buffer Security Check<\/a>, enabled by the \/GS<\/code> switch to the compiler. This feature is on-by-default as it protects against one of the most common security exploits. It creates a “security cookie” in functions that the compiler detects are vulnerable to buffer overruns. If an attacker writes past the end of the buffer over a return address, the address of an exception handler, or a vulnerable function parameter they will overwrite the security cookie. The runtime will check the integrity of the cookie before allowing execution to jump to this address or before returning these parameters.<\/p>\n
    Safe Exception Handlers<\/h4>\n
    Safe Exception Handlers<\/a> are another long-standing security feature. This feature is on-by-default but only applies to code generated for the x86 platform. When it is enabled, the linker will only produce an image if it can create a static table of the image’s safe exception handlers. This prevents an attacker from overwriting the target of exception handling control flow.<\/p>\n
    Dynamic Base and Address Space Layout Randomization<\/h4>\n
    Address Space Layout Randomization<\/a> (ASLR) is a technique that makes it harder for an attacker to predict target addresses for their attacks. When ASLR is enabled on your binary image the OS loader will load the image at a hard-to-predict base address. The \/DYNAMICBASE<\/code> switch<\/a> to the linker, which is on by default, enables the image to use ASLR.<\/p>\n
    Data Execution Prevention<\/h4>\n
    One common technique for attackers is to use data as executable code. Executing data that has been specially formatted as machine code is a powerful technique used by many languages, like .NET languages or JavaScript, in their Just-In-Time (JIT) compilers. But a C++ program shouldn’t normally need to execute data. Windows allows data sections to be marked as non-executable using a technique called Data Execution Protection (DEP)<\/a>. The \/NXCOMPAT<\/code><\/a> linker switch, on by default, specifies whether an image is compatible with DEP.<\/p>\n
    Control Flow Guard<\/h4>\n
    In 2014 we announced an exciting new security feature called Control Flow Guard<\/a>. The \/guard:cf<\/code> option instructs the compiler to analyze control flow for any indirect calls at compile time and records the results of that analysis in the compiled binary. It also puts a check in the binary before every indirect call that is checked by Windows when your code is run. Windows will call RaiseFastFailException<\/code> if any of these checks fails at runtime.<\/p>\n
    Upcoming Security Features<\/h4>\n
    We continue to innovate with new security features that benefit from our code generator\u2019s program analysis. Security requires \u201cdefense in depth<\/a>\u201d because attackers will always find a way to work around the protections you have in place now. We constantly have to find new ways to help protect your code at all levels.<\/p>\n
    Is your code secure?<\/h3>\n
    Good developer tools can do a lot to help you write solid and secure code but unfortunately, they can\u2019t do everything for you. You need to start with a good design that includes security appropriate for the environment our code will run in\u2014both when you deploy it and, potentially, for many years in the future, long after you might have expected your code to be rewritten, replaced, or just obsolete. Can your code be running in a connected environment? You need to plan for attacks, including those as simple as denial of service. Will your code handle sensitive user information? You need to plan for how your code will stand up to attackers who want to get at the data you handle.<\/p>\n
    Security isn\u2019t a feature that can be bolted onto a finished product. But good tools–such as those provided in the Visual C++ toolset–can help you write solid, secure code.<\/p>\n
    Thank you!<\/h4>\n
    Thank you for reading over this long list of security features provided at different points in your development process. And thanks to the hundreds of people who provide feedback and help us improve the C++ experience in Visual Studio.<\/p>\n
    If you have any feedback or suggestions for us, please reach out. We can be reached via the comments below, via email (visualcpp@microsoft.com<\/a>) and you can provide feedback via Help > Report A Problem in the product<\/a>, or via Developer Community<\/a>. You can also find us on Twitter (@VisualC<\/a>) and Facebook (msftvisualcpp<\/a>).<\/p>\n","protected":false},"excerpt":{"rendered":"
    Shareable link: https:\/\/aka.ms\/msvcsecurity \u70b9\u8fd9\u91cc\u770b\u4e2d\u6587\u7248 Every developer makes mistakes. No matter how careful you are when writing code, you will introduce bugs. And any bug can become a security vulnerability when software that runs in a connected environment or is used long past its initially planned lifespan. Code that isn’t correct is insecure code. The Microsoft […]<\/p>\n","protected":false},"author":312,"featured_media":35994,"comment_status":"open","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"footnotes":""},"categories":[1],"tags":[314],"class_list":["post-16275","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-cplusplus","tag-security"],"acf":[],"blog_post_summary":"
    Shareable link: https:\/\/aka.ms\/msvcsecurity \u70b9\u8fd9\u91cc\u770b\u4e2d\u6587\u7248 Every developer makes mistakes. No matter how careful you are when writing code, you will introduce bugs. And any bug can become a security vulnerability when software that runs in a connected environment or is used long past its initially planned lifespan. Code that isn’t correct is insecure code. The Microsoft […]<\/p>\n","_links":{"self":[{"href":"https:\/\/devblogs.microsoft.com\/cppblog\/wp-json\/wp\/v2\/posts\/16275","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/devblogs.microsoft.com\/cppblog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/devblogs.microsoft.com\/cppblog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/cppblog\/wp-json\/wp\/v2\/users\/312"}],"replies":[{"embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/cppblog\/wp-json\/wp\/v2\/comments?post=16275"}],"version-history":[{"count":0,"href":"https:\/\/devblogs.microsoft.com\/cppblog\/wp-json\/wp\/v2\/posts\/16275\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/cppblog\/wp-json\/wp\/v2\/media\/35994"}],"wp:attachment":[{"href":"https:\/\/devblogs.microsoft.com\/cppblog\/wp-json\/wp\/v2\/media?parent=16275"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/cppblog\/wp-json\/wp\/v2\/categories?post=16275"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/cppblog\/wp-json\/wp\/v2\/tags?post=16275"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}