The Security Development Lifecycle

Static Analysis Tools and the SDL (Part Two)

2009-07-06T22:42:26Z

Hi, Bryan here. Michael wrote last week on static analysis for native C/C++ code, and this week I’ll be following up by covering the tools we use for managed static analysis. The SDL requires teams writing managed code to use two static analysis tools: FxCop and CAT.NET. Both of these tools are freely available to the public, and both tools also integrate very nicely into Visual Studio. If you’re not already using these tools in your development process, I highly recommend downloading and evaluating them, but first let’s take a quick look at each of them.

FxCop

You may be more familiar with FxCop as the “Code Analysis” feature found in Visual Studio Team Developer (and Team Suite) 2005 and later. If you’re already using Visual Studio, it’s a no-brainer to enable FxCop code analysis: open your solution’s Properties window (or your web site’s Website menu item), navigate to the Code Analysis tab, and check the “Enable Code Analysis on Build” option. If you’re not using VS, you can download the latest version of the standalone FxCop tool (1.36) here.

FxCop comes preinstalled with many useful rules, including rules to help ensure performance (for example, “Do not cast unnecessarily”), globalization (“Do not hardcode locale specific strings”), and maintainability (“Variable names should not match field names”), but the SDL is mainly concerned with the security rules. The SDL requires teams to enable all of the FxCop security rules and fix any violations.

Many of the security rules are focused on detecting misuses of .NET Code Access Security policy. Some examples:

· Do not indirectly expose methods with link demands. LinkDemand checks only the immediate caller’s permissions, it does not perform a complete stack walk like Demand does. Calling a LinkDemand-protected method from an unprotected method essentially allows the caller to bypass the security check completely. In general, Demand is much safer than LinkDemand; any misuse of LinkDemand can create a potential vulnerability to luring attacks.

· Secure serialization constructors. If you place security demands on a type’s regular constructors, you must also place them on its serialization constructors, or else the demands could be bypassed.

· APTCA methods should only call APTCA methods. Assemblies marked with the AllowPartiallyTrustedCallersAttribute (APTCA) that call into other assemblies not marked with APTCA can be used by attackers to perform luring attacks. The attacker (calling from partially-trusted code) could simply call the APTCA method that would then call the protected method on his behalf. (Note that the use of APTCA in itself is banned by the SDL; if it’s absolutely necessary then a manual review of all APTCA methods must be made to ensure no luring attacks are possible.)

CAT.NET

While the built-in FxCop security rules are generally focused more on testing whether you’ve used security features in the right way (although it’s easy to write your own FxCop rules to check for almost anything you want, which we’ll talk about later in this post), CAT.NET is focused more on testing whether you’ve written your other features securely. This is a subtle but important distinction and both types of tests are necessary to help ensure secure code. By default, CAT.NET tests for the following vulnerabilities:

· Cross-Site Scripting

· SQL Injection

· File Canonicalization issues

· XPath and LDAP Injection. These attacks work on exactly the same principle as SQL injection (user data is interpreted as code), but for XPath and LDAP queries instead of SQL queries.

· Redirection to User-Controlled Site (aka Open-Redirect Phishing)

· Process Command Injection. This is yet another attack that works on the data-interpreted-as-code principle. In this case, the user supplies improperly validated arguments to a command-line process, which can allow the user to execute arbitrary processes on the server.

CAT.NET also differs from FxCop in the way it performs analysis. Both tools are static IL analysis tools, meaning that they analyze the compiled Common Intermediate Language (CIL) bytecode and not the raw C#/VB.NET/etc source itself. However, FxCop works on an introspection basis, iterating through each assembly type, member, resource, etc, while CAT.NET works by creating a directed call graph and looking for execution paths that represent potential vulnerabilities.

For example, if you wanted a rule to make sure your code doesn’t use MD5 (because it’s been banned by the SDL), FxCop would be a natural choice: you could simply write one method that would iterate through the all of the members in the assembly looking for instantiations of MD5Cng or MD5CryptoServiceProvider classes. On the other hand, if you wanted a rule to make sure incoming querystring data is validated by a regular expression before being adding to session state, CAT.NET would be a better choice. You would create a new rule XML file, adding HttpRequest.QueryString.Item and HttpRequest.Params.Item as “source” elements, HttpContext.Session.Item as a “sink” element, and System.Text.RegularExpression.Regex as a “filter” element. CAT.NET would then analyze the potential execution paths of the application, flagging any data flows that originate with HttpRequest.QueryString or HttpRequest.Params and end at HttpContext.Session without first passing through RegularExpression.Regex.

CAT.NET can run standalone or integrated into Visual Studio, but in either case you’ll need to download it from microsoft.com: you can find the 32-bit version of CAT.NET here and the 64-bit version here. Microsoft online services teams have been using CAT.NET internally for quite a while, and I was extremely pleased when the Microsoft IT Information Security Tools team (formerly the Connected Information Security Group) released it externally.

Code Contracts

Finally, as an interesting look at an upcoming technology, check out the DevLabs Code Contracts project. Code Contracts let you annotate your code to express required pre- or post-conditions on methods, just like SAL for native code. For example, you could require incoming method parameter values to conform to a specified regular expression, or require outgoing return values to be non-null. You can use Code Contracts both as a static analysis tool, to test for possible contract violations, and as runtime checks to actually enforce the conditions set. Like both FxCop and CAT.NET, Code Contracts can be installed either standalone or integrated with Visual Studio.

The SDL Optimization Model and Static Analysis

If you’re following the SDL Optimization model, use of static analysis tools is deemed a requirement for the ‘Advanced’ maturity level.

Static Analysis Tools and the SDL (Part One)

2009-06-29T16:42:30Z

Hi, Michael here.

This is part one of a two part series of posts by myself and Bryan Sullivan; I will cover the static analysis tools we use at Microsoft (and make available publicly) for analyzing unmanaged (ie; Native) C and C++ code, and Bryan will cover managed code static analysis in a later post.

I’m a huge fan of static analysis tools; actually, I’m a fan of any tooling that beneficially automates any portion of the software development process. Software development is a complex business, and anything you can do to make the process more repeatable, predictable and reduces ‘friction’ is a big win in my book.

There are many benefits to using static analysis tools. The most important reasons include:

Static analysis tools can scale: they can review a great deal of code very quickly; this is something humans cannot do very well.
Static analysis tools don’t get tired. A static analysis tool running for four straight hours at 2:00 in the morning is just as effective as if it runs during business hours. You can’t say the same thing about human reviewers!
Static analysis tools help developers learn about security vulnerabilities. Over the years, I’ve met a small number of developers who had bugs flagged in their code by static analysis tools, and they never knew what the bugs were until the tool posted a sign saying, “Security bug, right here!”

Before I dive into static analysis tools in detail, it’s worthwhile explaining what ‘static analysis’ is. Static analysis is a method of analyzing program code without actually running the code. Generally, the tool will build an internal model of the code and analyze potential program flow through the code making assumptions about the data. For example, the following code may or may not be a real vulnerability:

char foo[4];
foo[i] = 0;

because it depends on the value of ‘i’; if ‘i’ is in the range 0..3 and can only ever be in the range 0..3 then there is no security vulnerability, so the static analysis tool has to determine if this condition is possible. Clearly, it’s simple to determine that the following code is safe, because the index is constrained right next to the code that writes to the array:

char foo[4];
if (i>=0 && i<=3) foo[i] = 0;

But things get more complex if the index is validated in remote parts of the code. It is this level of analysis that determines if a tool is noisy: a tool that flags too many issues (false positives) because it missed a validity check will rapidly annoy a developer.

I want to point out that static analysis is not grep, static analysis tends to be more robust. That does not mean grep is not useful, for example, if you have a set of banned functionality such as banning MD4 and MD5 (as the SDL does, along with other crypto algorithms) then grep’ing for MD4 and MD5 is totally valid, probably low noise and requires next to zero engineering effort.

I also want to point out that the SDL focuses on using static analysis tools to find security vulnerabilities. Under the SDL umbrella, we would not require development teams use static analysis tools that didn’t find security issues. A tool that does not find security bugs is not a useless tool; we just would not make it an SDL requirement.

It’s important to point out that static analysis tools work in tandem with human code reviewing experts. Tools tend to find a lot of bugs quickly, but expert code reviewers are better at finding a smaller number of hard-to-find security bugs. I wrote an article for IEEE Security & Privacy a few years back describing the methods I use to review code for security bugs.

Static analysis tools have been used for many years at Microsoft. We started in earnest with a tool named PREfix when we acquired Intrinsa. PREfix is aimed at finding general code quality bugs in C and C++ and has proven very effective over the years. The main downside to PREfix is it is big, and generally is run centrally rather than each developers’ desktop. So PREfix begat PREfast, a smaller desktop version of PREfix. PREfast has the advantage of being relatively quick to run (it only doubles compile times!) but it suffers from only being intra-procedural; in other words, its view of your code is very small, while PREfix is inter-procedural and can evaluate conditions in far-flung regions of your code. If you need to know why that’s important, refer to the example code above!

PREfix and PREfast both support the Standard Annotation Language (SAL) which I have addressed a couple of times in the past. SAL allows you to describe function contract semantics to help tools like PREfix and PREfast find more security bugs. SAL is used throughout Visual C++.

PREfast is available in Visual C++ today as the /analyze option, it’s also freely available in the Windows Device Driver Kit (as prefast.exe) and Software Development Kit (as /analyze).

What You Should Do

If you write native C or C++ code, you should:

Compile at least once a day with /analyze
Use SAL to annotate your function prototypes, this will help the static analysis functionality in the compiler find many more bugs.

The following warnings should be analyzed, as they are probably security issues:

6029 6053 6054 6057 6059 6063 6067 6200 6201 6202 6203 6204 6209 6248 6277 6298 6305 6308 6383

Finally, for extra credit, look for the following warnings that are generated by the compiler and not by the static analysis tools:

4700 and 4701

Both of these relate to uninitialized data and to enable these warnings either compile with warning level 4 (/W4), or if you’re not daring enough, use /W3 augmented with the following:

/W3 /WX /we4701/we4700

The SDL Optimization Model and Static Analysis

If you’re following the SDL Optimization model, use of static analysis tools is deemed a requirement for the ‘Advanced’ maturity level.

Summary

In summary, the SDL mandates static analysis tools for C and C++ code. If you are currently not using static analysis tools in your development environment, you should. If you’ve never run static analysis tools then the chances are good you’ll find some ‘interesting’ bugs!

Good thinking about threat models

2009-06-26T17:56:29Z

We wanted to take a minute to point out this good post from Gunnar Peterson. He’s right, and it’s worth repeating: we threat model not to find threats, but to find and implement countermeasures. We’re glad to see people building on our work like this.

Microsoft & Adobe: Protecting our customers together

2009-06-17T17:59:45Z

Hey everyone, Jeremy Dallman here. Today I will be co-blogging with David Lenoe (Group Program Manager, Adobe Secure Software Engineering Team (ASSET)). Now, here’s the story behind the Microsoft and Adobe security pairing …

A couple of years ago, Microsoft and Adobe made a decision to work together on security rather than address our similar security goals within the vacuum of each company. Our security teams have since been working closely together with the clear goal of protecting our mutual customers. This collaborative relationship enables faster implementations of security protection through the lifecycle processes both companies offer (Microsoft’s Security Development Lifecycle - SDL, Adobe’s Secure Product LifeCycle - SPLC), and allows us to share best practices learned over the years. In turn, each company learns about new ways to apply their respective lifecycle plan, thereby helping to provide our customers with a more secure computing environment.

Through the last couple of years we have had conversations about defining and implementing security requirements, prioritizing security risk, threat modeling, the benefits of compiler/linker flag protections, fuzzing, and penetration testing. We’ve even shared data on security incidents and response.

Implement proactive engineering protections

With support from the security folks at Microsoft, ASSET helped the Adobe product teams set the security-related C++ compiler and linker flags such as /NXCOMPAT, /DYNAMICBASE (ASLR), /GS, and /SAFESEH. Working together, we were able to address compatibility issues and get these protections in place for both Adobe Flash Player and Adobe Reader. These protections have helped to mitigate entire classes of vulnerabilities in Microsoft products and will improve the security of Adobe products as well.

Encourage consistent security updating

Most recently, we worked together to publish some 2008 attack data on vulnerabilities affecting Microsoft and Adobe products in the Microsoft Security Intelligence Report. Our goal was to emphasize to our mutual customers that installing security updates for Microsoft, Adobe and other third-party applications is very important. Having customers update promptly when Microsoft or Adobe addresses vulnerabilities is the best way to avoid the rapid spread of attacks.

Adopt security tools

After the Microsoft Security Sciences team released !exploitable in March, some of Adobe’s security testing teams started using it on their own products along with WinDbg to analyze the results of fuzz testing. Microsoft and Adobe continue to work together to address questions and help improve the effectiveness of this tool.

Some of Adobe’s development teams also use static analysis tools like /analyze and FxCop to identify potential security vulnerabilities in source code.

Share response information

By collaborating amongst the teams at Microsoft and Adobe, the Microsoft Security Response Center (MSRC), Microsoft Vulnerability Research (MSVR) program, the Microsoft Security Research and Defense team, the Adobe Product Security Incident Response Team (PSIRT) and Adobe Secure Software Engineering Team (ASSET), respectively, we have also been able to identify security trends and more rapidly address vulnerabilities.

Continue working together

We consider the collaboration between Microsoft and Adobe to be a great success for both companies. We look forward to continuing to work together and discovering new and better ways that we can protect both Microsoft and Adobe customers in the future.

Technorati Tags: Microsoft,Adobe,security,SDL,SPLC

A Declspec SAL to Attribute SAL Rosetta Stone

2009-06-11T17:19:33Z

Hi, Michael here.

A while back I wrote a blog post explaining the Standard Annotation Language (SAL) which is a technology we use to help static analysis tools find more bugs, including security vulnerabilities, in C and C++ code. If you look closely at VC++ 2005 and VC++ 2008, you’ll notice that almost all function prototypes are SAL annotated, which means you get the benefit of all the SAL work we did. But you might have also notice that the annotation style between the two compiler versions is different.

For example, in Visual C++ 2005, realloc() is annotated like this:

__checkReturn __bcount_opt(_NewSize) 
    void * __cdecl realloc(
        __in_opt void * _Memory, 
        __in size_t _NewSize);

But in VC++ 2008, realloc() is annotated like this:

_Check_return_ _Ret_opt_bytecap_(_NewSize) 
    void * __cdecl realloc(
        _In_opt_ void * _Memory, 
        _In_ size_t _NewSize);

So what’s going on? In short, there is an updated flavor of SAL that offers greater flexibility and strictness. The older version is usually referred to as ‘declspec’ SAL, and the newer version is called ‘attribute’ SAL. They get their names from the structure of the underlying primitives and the following should make it clear:

SAL Macro	SAL Primitives
Declspec SAL void Foo( __in_bcount(cb) BYTE* pBuf, size_t cb );	void Foo( __declspec("SAL_pre") __declspec("SAL_valid") __declspec("SAL_pre") __declspec("SAL_deref") __declspec("SAL_readonly") __declspec("SAL_pre") __declspec("SAL_readableTo(byteCount(""cb""))") BYTE* pBuf, size_t cb );
Attribute SAL void Foo( _In_bytecount_(cb) BYTE* pBuf, size_t cb );	void Foo( [SA_Pre (Null=SA_No,ValidBytes="cb")] [SA_Pre(Deref=1,Valid=SA_Yes)] [SA_Pre(Deref=1,Access=SA_Read)] BYTE* pBuf, size_t cb );

Aren’t you happy we created macros for the low-level primitives!? You should never have to use the low-level primitives in your code: the table is to show you why the two SAL formats got their names.

So why a new SAL syntax? I have good news and really good news. First, the good news: other than a simple macro syntax change, there is not a lot new to learn in part because the macros are similar (not identical, however) and the major difference, the low-level primitives, are abstracted away.

Now for the really good news. Attribute SAL is much more rigorous than declspec SAL, which means analysis tools can find more bugs with lower false positives (‘noise’). For example, declspec SAL is often silent in the face of an incorrect annotation.

The introduction of attribute SAL does not mean declspec SAL is dead, but it does mean that we will not be investing any more resources into declspec SAL, all our energy improving SAL and our analysis tools use of SAL will be in attribute SAL. At a pragmatic level, this means:

· If you have already invested in using declspec SAL you should migrate over to attribute SAL as time allows, and use new attribute SAL for new functions. Both syntaxes can co-exist.

· If you have never used SAL, you should use attribute SAL. As far as you’re concerned, declspec SAL never existed.

One noticeable difference in macro names is the use of declspec SAL’s “count” and attribute SAL’s “cap” and “count.” The former is a buffer size in elements or bytes, but the latter two are the buffer’s writing capacity and the size of the buffer for reading, respectively.

An important addition to attribute SAL is _Printf_format_string_ which can be used to find many printf-related format-matching ills.

The following table shows some of the major differences:

	declspec SAL	Attribute SAL
Syntax	Loose, allows macros in places they don’t make sense	Strict, annotations can be only put on parameters and return values
Consistency checks	Few, allows wrong macros	Many, exhaustive set of warnings for wrong\inconsistent annotations
Wrong annotations	Ignored	Flagged
Constant expressions buffer sizes	Simple expressions only	Fully supported including templates, but requires different macros.
Return values	Loose syntax and consistency rules allow the use of ‘__out’ family	Special set of macros for return values required
Naming consistency	Overloaded use of ‘count’ for writable and readable extent. Hard to understand _full and _part postfixes	Consistent use of ‘cap’ (capacity) for writable extent and ‘count’ for readable extent

As noted in the table above, there is one minor drawback to using attribute SAL. If you use constant expressions as count or cap arguments, you must use a special set of macros, which is a little less elegant than declspec SAL:

void Foo( _In_count_c_( 8 ) int* rgInt );

versus

void Foo( __in_count( 8 ) int* rgInt );

Note the _c_ portion of the attribute syntax, which is not needed when using declspec macros. With that said, attribute syntax supports accept any C++ conformant constant expression including enums and template arguments, but decspec SAL supports only simple expressions.

An Example

To put his altogether, let’s look at some simple code, and see how the VC++ 2008 /analyze static analysis performs when faced with the different SAL types.

First, declspec SAL:

   1: #include "stdafx.h"

2:

   3: struct SomeStruct {

   4:     int x;

   5:     float f;

   6: };

7:

   8: bool FuncOne(__in_z_opt const char* filename);

   9: void FuncTwo(const char *pFormat, ...);

  10: void FuncThree( __in const SomeStruct* setup );

  11: void FuncFour(__in HWND h, __in char *sz);

12:

  13: void TestWarnings() {

  14:     char b;

  15:     FuncOne(&b);

  16:     FuncTwo("%d %p %d", 10.0, "Hello");

  17:     FuncThree(0);

  18:     SomeStruct blah;

  19:     FuncThree(&blah);

20:

  21:     char buff[100];

  22:     FuncFour(NULL,buff);

  23: }

When compiled with /W4 /analyze, the compiler gives us:

warning C6309: Argument '1' is null: this does not adhere to function 
specification of 'FuncThree'
warning C6309: Argument '1' is null: this does not adhere to function 
specification of 'FuncFour'
warning C6387: 'argument 1' might be '0': this does not adhere to the 
specification for the function 'FuncThree': Lines: 14, 15, 16, 17
warning C6387: 'argument 1' might be '0': this does not adhere to the 
specification for the function 'FuncFour': Lines: 14, 15, 16, 17, 18, 19, 21, 
22

Now, let’s take the same code, but decorate the function prototypes with attribute SAL rather than declspec SAL.

   1: #include "stdafx.h"

2:

   3: struct SomeStruct {

   4:     int x;

   5:     float f;

   6: };

7:

   8: bool FuncOne(_In_opt_z_ const char* filename);

   9: void FuncTwo(_Printf_format_string_ const char *pFormat, ...);

  10: void FuncThree(_In_ const SomeStruct* setup );

  11: void FuncFour(_In_ HWND h, _In_ char *sz);

12:

  13: void TestWarnings() {

  14:     char b;

  15:     FuncOne(&b);

  16:     FuncTwo("%d %p %d", 10.0, "Hello");

  17:     FuncThree(0);

  18:     SomeStruct blah;

  19:     FuncThree(&blah);

20:

  21:     char buff[100];

  22:     FuncFour(NULL,buff);

  23: }

warning C6273: Non-integer passed as parameter '2' when integer is required 
in call to 'FuncTwo': if a pointer value is being passed, %p should be used
warning C6064: Missing integer argument to 'FuncTwo' that corresponds to 
conversion specifier '3'
warning C6309: Argument '1' is null: this does not adhere to function 
specification of 'FuncThree'
warning C6309: Argument '1' is null: this does not adhere to function 
specification of 'FuncFour'
warning C6001: Using uninitialized memory 'b': Lines: 14, 15
warning C6387: 'argument 1' might be '0': this does not adhere to the 
specification for the function 'FuncThree': Lines: 14, 15, 16, 17
warning C6001: Using uninitialized memory 'blah': Lines: 14, 15, 16, 17, 18, 
19
warning C6387: 'argument 1' might be '0': this does not adhere to the 
specification for the function 'FuncFour': Lines: 14, 15, 16, 17, 18, 19, 21, 
22

As you can see, using attribute SAL found many more code bugs, and all of them are real. I’ll let you sift through the list to see what attribute SAL found over and above declspec SAL! There are some duplicate bugs, however.

If you want to learn more about SAL, I would recommend you simply open sal.h and read the comments and examples.

The Rosetta Stone

Below is a partial Rosetta Stone to help you convert between the two SAL syntaxes if you need to do so.

Declspec	Attribute
__in	_In_
__in_opt	_In_opt_
__in_z_opt	_In_opt_z_
__out	_Out_
__out_opt	_Out_opt_
__inout	_Inout_
__inout_opt	_Inout_opt_

__in_ecount(count)	_In_count_(count)
__in_bcount(count)	_In_bytecount_(count)
__in_xcount(count)	_In_count_x_(count)
__in_ecount_z(count)	_In_z_count_(count)
__in_bcount_z(count)	_In_z_bytecount_(count)
__in_xcount_z(count)	_In_z_count_x_(count)
__in_ecount_opt(count)	_In_opt_count_(count)
__in_bcount_opt(count)	_In_opt_bytecount_(count)
__in_xcount_opt(count)	_In_opt_count_x_(count)
__in_ecount_z_opt(count)	_In_opt_z_count_(count)
__in_bcount_z_opt(count)	_In_opt_z_bytecount_(count)
__in_xcount_z_opt(count)	_In_opt_z_count_x_(count)

__out_ecount(count)	_Out_cap_(count)
__out_bcount(count)	_Out_bytecap_(count)
__out_xcount(count)	_Out_cap_x_(count)
__out_ecount_z(count)	_Out_z_cap_(count)
__out_bcount_z(count)	_Out_z_bytecap_(count)
__out_xcount_z(count)	_Out_z_cap_x_(count)
__out_ecount_part(cap,count)	_Out_cap_post_count_(cap, count)
__out_bcount_part(cap,count)	_Out_bytecap_post_bytecount_(count)
__out_ecount_full(capcount)	_Out_capcount_(capcount)
__out_bcount_full(capcount)	_Out_bytecapcount_(capcount)
__out_ecount_opt(count)	_Out_opt_cap_(count)
__out_bcount_opt(count)	_Out_opt_bytecap_(count)
__out_xcount_opt(count)	_Out_opt_cap_x_(count)
__out_ecount_z_opt(count)	_Out_opt_z_cap_(count)
__out_bcount_z_opt(count)	_Out_opt_z_bytecap_(count)
__out_xcount_z_opt(count)	_Out_opt_z_cap_x_(count)
__out_ecount_part_opt(cap,count)	_Out_opt_cap_post_count_(cap,count)
__out_bcount_part_opt(cap,count)	_Out_opt_bytecap_post_bytecount_(count)
__out_ecount_full_opt(capcount)	_Out_opt_capcount_(capcount)
__out_bcount_full_opt(capcount)	_Out_opt_bytecapcount_(capcount)

__inout_ecount(count)	_Inout_cap_(count)
__inout_bcount(count)	_Inout_bytecap_(count)
__inout_xcount(count)	_Inout_cap_x_(count)
__inout_ecount_full(count)	_Inout_count_(count)
__inout_bcount_full(count)	_Inout_bytecount_(count)
__inout_xcount_full(count)	_Inout_count_x_(count)
__inout_ecount_z(count)	_Inout_z_cap_(count)
__inout_bcount_z(count)	_Inout_z_bytecap_(count)
__inout_xcount_z(count)	_Inout_z_cap_x_(count)
__inout_ecount_opt(count)	_Inout_opt_cap_(count)
__inout_bcount_opt(count)	_Inout_opt_bytecap_(count)
__inout_xcount_opt(count)	_Inout_opt_cap_x_(count)
__inout_ecount_full_opt(count)	_Inout_opt_count_(count)
__inout_bcount_full_opt(count)	_Inout_opt_bytecount_(count)
__inout_xcount_full_opt(count)	_Inout_opt_count_x_(count)
__inout_ecount_z_opt(count)	_Inout_opt_z_cap_(count)
__inout_bcount_z_opt(count)	_Inout_opt_z_bytecap_(count)
__inout_xcount_z_opt(count)	_Inout_opt_z_cap_x_(count)

Acknowledgments

I would like to thank Hannes Ruescher (Dev Mgr in Office,) Dave Bartolomeo (Principal Software Design Engineer in Visual Studio) and Bruce Dawson (Principal Software Design Engineer in Windows) for their gracious help providing core content for this document.

Announcing SDL-LOB “Security Development Lifecycle for Line-of-Business Applications”

2009-06-05T16:55:00Z

Hi all, Anmol Malhotra here… I’m a Senior Security Engineer with Microsoft’s ACE (Assessment, Consulting & Engineering) Team. We are part of Microsoft Information Security group and our mission is to enable secure and reliable business for Microsoft and its customers. ACE Team is responsible for security, privacy and performance for line-of-business (LOB) applications at Microsoft. Since 2001, we have been working in identifying and reducing risk posed by applications in our enterprise. This experience has resulted in development of processes, tools and best practices to help develop and maintain secure applications for an enterprise. We developed the Security Development Lifecycle for Line-of-Business Applications (SDL-LOB) process which defines the standards and best practices for securing LOB applications.

As part of our continued commitment towards sharing security processes, and recommendations with our customers, we are excited to announce the new addition of detailed security requirements and recommendations for LOB applications with the release of Microsoft SDL version 4.1 on MSDN. SDL-LOB provides a mainstream approach to the SDL which focuses on development of applications which support business such as accounting, human resources (HR), payroll, supply chain management and resource planning applications etc.

Couple of things around this guidance –

a) This guidance is positioned exclusively for line-of-business applications or web applications and not for ISV/rich client and server application development.

b) It is important to emphasize that organizations should adapt rather than adopt the SDL-LOB process.

So here it is, Security Development Lifecycle for Line-of-Business Applications. Also look out for SDL-LOB blog series on the ACE Team blog starting in June. We’ll discuss the SDL-LOB phases and highlights.

Your comments & suggestions are very welcome.

A note on the recent SDL 4.1 process release...

2009-05-29T00:17:00Z

Hello all - Dave here...

Wanted to drop a quick note to talk about the SDL 4.1 process guidance that we released on May 19th...

While most of the attention and chatter from the development community has been focused on the announcement of the SDL Process Template for Visual Studio Team System and the addition of SAIC and SANS to the SDL Pro Network, the SDL 4.1 documentation release has a few important points to touch on.

First, it demonstrates our ongoing commitment to process transparency - we released the SDL 3.2 process documentation for the first time at RSA 2008 along with a promise to update it on a regular basis. So here we are, just over a year later, with the latest changes. Many people in the IT and developer communities are curious about the individual requirements and recommendations that make up the SDL. Additionally, there has been a lot of interest on how a process like the SDL is applied at an organization the size of Microsoft - we think the new documentation does a good job at answering both these queries.

Second, there is a myth that I often hear repeated that the SDL "only works for Microsoft" or "is only suitable for development on Microsoft platforms." Honestly, that's a bit of a shocker for me. Security training, threat modeling, static code analysis, fuzz testing and other security actions performed as part of the SDL are *not* proprietary to Microsoft or the SDL. While the 4.1 documentation *is* focused on how the SDL is applied at MS, it doesn't require a Nobel Laureate to see that many of the things that make up the SDL are simply good security practices. So, I'd encourage people to take a look at the requirements and recommendations that are listed in the document and form your own conclusions. Fight the FUD.

Finally, we've illustrated the changes that one would expect of a living process - the expected fine tuning of our SDL requirements and recommendations to reflect changes in the security space. In addition, we have included information on how the SDL is applied to online services (i.e. Microsoft publicly available websites) and how we use the SDL to build line-of-business (LOB) applications for internal use at Microsoft. The changes specific to online services and LOB are called out in the text for easier review.

So that's it - a quick snapshot of the 4.1 process. As before, it's available both as web guidance on the MSDN Security Developer Center and as a Word document from the MSDN Download Center.

As always, comments are welcome!

SDL Template and Agile...

2009-05-22T18:18:00Z

Hello all - Dave here...

We have been pleased thus far with the reaction from the developer community to our release of the SDL Template for Visual Studio Team System. However, some folks in the developer community have inquired about applying the template to agile methods.

The SDL template is a software manifestation of the Microsoft SDL requirements and recommendations as we apply them to typical Microsoft “packaged product” development projects. Most of those projects are using native code and following a spiral development methodology.

Agile methods are also used at Microsoft, but it’s critically important that we fully examine how the SDL can be integrated into agile methods to ensure that we get it right. We’ve already learned that simply taking the SDL for spiral methodology and applying the entire SDL at each agile sprint is not the right answer. We're working to bring the benefits of the Microsoft SDL to users of the Visual Studio Team System MSF for Agile template in the near future.

New SDL Pro Network Members: SANS and SAIC

2009-05-21T15:50:00Z

When I joined the SDL team last fall, the SDL Pro Network had launched as a one-year pilot program. Upon returning from maternity leave, I took over management of the SDL Pro Network. I have been working on formalizing the program in order to bring it from pilot phase into a full blown partner program, to launch after November 2009. I have also been working on bringing new consulting services and training members into the fold, even during this pilot phase of the program.

On May 19, the SANS Institute, one of the most trusted and largest sources for information security training, certification & research in the world, and SAIC, a company of over 45,000 employees worldwide with expertise in national security, energy and the environment, critical infrastructure and health, were also added to the SDL Pro Network in an effort to further broaden the SDL’s reach.

In joining forces with these two new SDL Pro Network members, Microsoft’s SDL team is bringing more options for world-renowned security training and consulting services to new developers around the world.

Please join me in welcoming SANS and SAIC into the SDL Pro Network.

-Katie Moussouris, Senior Security Strategist, SDL

Making Secure Code Easier

2009-05-19T16:31:00Z

Technorati Tags: SDL,SDL Process Template,Tools

Hi everyone! Jeremy Dallman here. I would like to announce a new and easier way to integrate the SDL into your development lifecycle.

In the year since we released the Microsoft SDL Process Guidance documentation, companies interested in adopting the SDL have often asked us “where do I start”? In the past year, we’ve provided the SDL Optimization Model, The SDL Threat Modeling Tool, and the SDL Pro Network as great options to get you started. Quite often, the follow-up comment has been “I just need a way to practically apply the SDL in my development lifecycle… can’t you just put it into Visual Studio?” In order to successfully integrate security into their development process, the people who own a security initiative realize that they need to introduce secure development practices and the SDL with minimal impact on their existing development frameworks and as part of the familiar environment.

Today we are making available the Microsoft SDL Process Template.

The SDL Process Template is a free downloadable template for Visual Studio Team System that integrates the SDL directly into a customer’s software development environment. Because it integrates with the team and process features of Team System, you do need a Team Foundation Server to manage your work. This is our first comprehensive offering that addresses all phases of the SDL from Requirements through Release.

By taking advantage of the rich functionality in Visual Studio Team System and Team Foundation Server, we are now able to offer an SDL solution that reduces the barrier to entry for SDL adoption, provides auditing for satisfying the security requirements, and demonstrates security return on investment. The SDL Template is intended to provide the foundational components of the SDL for every phase of your development project.

How to check it out for yourself

We hope you will take the time to download the SDL Process Template and consider using it to integrate security and the SDL into your team project. If you do not currently use Visual Studio Team System, but would like to evaluate the SDL Process Template, evaluation versions in both VPC and Hyper-V environments are available for download. You can simply upload the SDL Process Template into that virtual environment and check it out for yourself.

A quick walk-through

Here is a quick preview of the basic functionality the SDL Process Template offers:

Process Guidance: Integrated SDL Overview, SDL documents, and How to customize

After installation completes and a new Team Project is created, the first page that appears is the Process Guidance page. This page provides everyone on the project with:

A brief overview of the SDL
Five steps for Getting Started on an SDL project
Details on customizing the template and extending it for third party security tools

Below: The SDL Process Guidance “front page”

SharePoint: SDL Document Library and Project dashboard

Since SharePoint is included with Visual Studio Team System, The basic SharePoint site provides a single location for all project participants to get a common view of project status, related announcements and dates, and access the large document library.

Below: the SharePoint site serves as a project dashboard

SDL Requirements: Pre-loaded SDL work items ready to triage

By selecting the “All SDL Tasks” query the team can find the pre-populated list of all SDL Requirements and Recommendations. No more trying to figure out where to start when it comes to defining security requirements! The SDL Template also provides a custom work item that allows you to create and add your own unique requirements or recommendations.

Below: all SDL Requirements and Recommendations pre-loaded and ready to triage

SDL Check-in Policies: Enforce SDL policy with existing VS features

Developers care about security, but they want it to be intuitive. We have provided check-in policies that will ensure every set of code is taking advantage of the SDL required compiler/linker flags and Code Analysis features already in Visual Studio. This will eliminate entire classes of security weaknesses from your code. A Security Code Review work item is also included to support enforcement of security code reviews for security-sensitive code.

Below: Setting Check-in policies

Below: Check-in policies in action

Customized Security bugs: Tag and track Cause, Severity, and STRIDE Effect

Testers want to be able to emphasize the importance of a security bug and properly communicate the impact to their product. The default “bug” work item now has customized security fields so you can identify security cause, severity, and security effect (using STRIDE), and mark a bug as Blocking or Not Blocking. This feature allows you to track and search for security-specific bugs.

Below: Identifying a bug as a security issue

Final Security Review: Track and audit the state of all active security bugs, completion of SDL tasks, and effectiveness of security tools

The entire team and especially senior management want an easy-to-read document that summarizes the security work completed. The Final Security Review Report and Security Bugs Report provide an auditable set of evidence that details security work completed as well as deferred tasks.

Page One: status of all bugs marked as Security Bugs
Page Two: completion status for the SDL Requirements and Recommendations
Page Three: security bugs found by all tools integrated with the template

Below: Page 1 of the Final Security Review

Below: Page 2 of the Final Security Review

Threat modeling: Seamless integration with the SDL Threat Modeling Tool

Threat modeling is a critical part of your early design process. It informs architects of the attack surface, provides insight for the developers to write more secure code, and enables testers to more effectively build test cases to verify mitigations. The SDL Process Template includes a script that will convert SDL Threat Modeling tool issues into security bugs and hook into the reporting piece of the template.

~~~~~~~

We hope you will take a look at the SDL Process Template and consider using it to ease adoption of the SDL in your development teams. As we move forward with more SDL offerings, our plan is to integrate any tools and guidance into the SDL Process Template – making it a dynamic foundation for an end-to-end SDL solution.

We look forward to your feedback as you download and begin using the SDL Process Template to make your code more secure.

Please Join me in welcoming memcpy() to the SDL Rogues Gallery

2009-05-14T21:41:00Z

Over the last few years I have written a number of articles, papers and books describing some of the dangers of using various buffer-manipulating C runtime functions. Well-known examples of bad function calls include strcpy(), strcat(), strncpy(), strncat(), gets() and their foul brethren. The SDL bans these and many other functions with dubious security history. But, when it comes to banning functions, we must tread a very fine line because we can’t just ban something because it looks odd, or that gut instinct tells us it’s bad, we can only ban functionality that has been demonstrated to cause security vulnerabilities and only if there is a viable alternative.

Because we have seen many security vulnerabilities in products from Microsoft and many others, including ISVs and competitors, and because we have a viable replacement, I am “proud” to announce that we intend to add memcpy() will to the SDL C and C++ banned API list later this year as we make further revisions to the SDL. Right now, memcpy() is on the SDL Recommended banned list, but will soon be added to the SDL banned API requirement list now that we have more feedback from Microsoft product groups.

The following security updates all have one thing in common: memcpy().

· MS03-030 (DirectX)

· MS03-043 (Messenger Service)

· MS03-044 (Help and Support)

· MS05-039 (PnP)

· MS04-011 (PCT)

· MS05-030 (Outlook Express)

· CVE-2007-3999 (MIT Kerberos v5)

· CVE-2007-4000 (MIT Kerberos v5)

· …many more!

It’s not just memcpy() that we’re banning; we will also ban CopyMemory() and RtlCopyMemory(), and the replacement function is memcpy_s().

Banning memcpy() in your code

You too should start banning memcpy() in your new code, here’s what you can do right now:

Add the following line of code to a common header file:

#pragma deprecated (memcpy, RtlCopyMemory, CopyMemory)

Every time the compiler sees an instance of the banned functions, you’ll get the following warning:

warning C4995: 'memcpy': name was marked as #pragma deprecated

In Visual C++, you can also add this early in a common header:

#define _CRT_SECURE_WARNINGS_MEMORY

And you will get warnings like:

warning C4996: 'memcpy': This function or variable may be unsafe. Consider using memcpy_s instead. To disable deprecation, use _CRT_SECURE_NO_WARNINGS. See online help for details. c:\program files\microsoft visual studio 9.0\vc\include\wchar.h(1201) : see declaration of 'memcpy'

You can deprecate these functions if you’re using gcc by poisoning them:

#pragma GCC poison memcpy RtlCopyMemory CopyMemory

Fixing memcpy() calls

Thankfully, it’s pretty simple to migrate a call to memcpy() to a safer call to memcpy_s(); the big difference is memcpy_s() takes one extra parameter: the size of the destination buffer. If nothing else, memcpy_s makes you think about the size of the target buffer.

The SAL-decorated function signature in VC++ 2008 is:

errno_t __cdecl
    memcpy_s(
        _Out_opt_bytecap_post_bytecount_(_DstSize, _MaxCount)
                void * _Dst,
        _In_ rsize_t _DstSize,
        _In_opt_bytecount_(_MaxCount) const void * _Src,
        _In_ rsize_t _MaxCount
    );

All you need to do is update calls to memcpy() by adding the size of the destination buffer. So calls like this:

char dst[32];

memcpy(dst,src,len);

becomes

char dst[32];

memcpy_s(dst,sizeof(dst), src,len);

Of course, you can easily make a call to memcpy_s() insecure by getting the buffer sizes wrong. The following code is no better than memcpy():

memcpy_s(dst,len, src,len);

You’ve been warned!

I wonder when Larry, Steve and Linus will start banning strcpy() in their products?

SDL for the 5-Person PHP Shop

2009-05-08T18:28:00Z

Hi, Bryan here. Regular readers of this blog know that I’m more likely to write technical posts about new defense tactics than I am to pontificate on the state of the security industry. However, while I was at the RSA Conference last month, I overheard a concerning misconception about the SDL that I’d like to address.

During a panel discussion on static- and source-analysis techniques, the panelists – Chris Wysopal of Veracode, Jerry Archer of Intuit, Mary Ann Davidson of Oracle, and Brian Chess of Fortify – had strayed somewhat from the original topic and into a discussion of security processes. At this point, several of them stated their belief that the SDL is only useful for large organizations running Windows, and that it wouldn’t work well for “5-person shops writing PHP.”

Now, I don’t believe that the only way to create secure software is to follow the SDL exactly the way we follow it at Microsoft. Not everyone building software is ready to commit as much time and energy to security as we do. For that matter, not everyone even needs to commit as much time and energy to security as we do! But everyone building software should be doing something to make that software more secure, which is exactly why we developed the SDL Optimization Model.

It’s true that if you have 1000 or more developers, you’ll probably want to eventually work your way up to the Dynamic level of the Optimization Model (where we see ourselves), but the 5-person PHP shop could greatly benefit from implementing the SDL at the Standardized level. At the Standardized level, you perform high-ROI security activities such as validating input and encoding output to defend against cross-site scripting attacks, using stored procedures to defend against SQL injection attacks, and fuzzing your application inputs to find unknown errors. These all sound pretty applicable to a 5-person PHP shop to me!

Ok, that’s definitely enough pontification for me for a while. The next time I post, I promise it’ll be something technical, like a comparison of various managed code static analysis tools or best practices for implementing cryptographic agility in your applications. Talk to you then.

The Open Source Quality Challenge

2009-05-01T14:02:00Z

Steve Lipner here,

Steve Bellovin, one of the pioneers of Internet security wrote a blog post about security, open source, and secure development process. It's worth reading if you're an open source fan, or if you're not.

My one quibble is that Steve refers to fixing bugs in a way that implies that just fixing bugs improves security. Our experience is that fixing bugs is not enough - you have to use tools and processes that specifically prevent security bugs from getting into the code in the first place.

But that’s a minor quibble. I think Steve's post is right on and a great read.

Security Development Processes and Transparency

2009-04-30T19:33:00Z

Hi, Michael here,

The following article, ”Major software makers fail security transparency test” caught my eye this morning, because it covers a topic of great interest to me;: companies documenting their security and privacy-related software development practices for the world to critique and perhaps more important, use.

As the article noted, Microsoft’s process has been public for nearly half a decade.

About two years ago I created a short presentation (attached) that asks many of the questions implied by the SD Times article. We support the proposition that vendors should be evaluated by criteria that are closer to the real security properties people want in their systems. Ask your vendors: are you investing in security or certificates?

The industry clearly has a long way to go, both in terms of improving security, and explaining how they achieve or plan to achieve their security objectives.

You Can’t Outrun the Bear, so Let’s Make a Deal

2009-04-23T20:27:00Z

Hello, Michael Weiss here. Nothing like having two Michaels around to confuse everyone. At least there are only two here. On a previous team, I was one of five Michaels.

Over the next several weeks, I’ll be posting a series of entries to help explain why I do what I do for the SDL team. Today marks the first of them. It’s a twofer, since the first part doesn’t fully make sense until you read the second part.

You Can’t Outrun the Bear

It’s a wild world out there. When you’re walking through the forest of the Internet, there are hungry bears all around you. The thing is, you can’t outrun the bear. Well, you can, but it’s very hard, not worth it, and not necessary, because you can avoid being eaten without having to outrun the bear in the first place. And contrary to popular belief, simply being faster than the other guy won’t necessarily protect you.

There are two ways you can avoid being eaten. The first is to have little meat, in which case your gross value is low. The other is to be fast enough that it would cost the bear more in energy to catch you than it would gain from eating you, in which case your gross cost is high. In either case, the bear makes a determination of your net value, that is, your gross value minus your gross cost. If the net value is positive, the bear chases you. If the net value is negative, the bear leaves you alone. This graph helps illustrate the point.

The blue line represents zero net value. As long as you are above the blue line, you have a negative net value so you’re safe; if you’re under the line, you have a positive net value so you’re dinner. In software, if you’re the green dot in the Dinner Zone, how can you move toward the Safe Zone? One way is to increase the gross cost to your attackers, by closing off the easy avenues of attack. The SDL was created to provide a mechanism to systematically do this.

While the SDL can move you toward the Safe Zone, it’s not necessarily going to get you all the way there. But that’s OK, because in the real world, you’re not the only bear food.

Let’s assume on this second graph that you are represented by the green dot, and some other potential target (your buddy, maybe?) is represented by the orange dot. You have a more secure system than him (your dot is higher up, costing the attacker more), so the orange dot person gets targeted instead of you. But what about that other person (represented by the red dot)? Sure, you have a more secure system, but you’re also a more valuable target (your dot is farther to the right). Since you’re farther from the blue line than the red person is, the attacker will go after you before working on the red person; you have a higher net value, despite having a higher gross cost.

In other words, just being more secure isn’t enough if you’re also a more valuable target.

Decreasing your gross value is rarely easy. For example, if you’re a bank, you could choose not to have any money. Willie Sutton would certainly lose interest in you. At the same time, your value as a bank is gone, too…hardly a sustainable business model. Besides, attackers rarely know exactly what they will gain from a successful attack on you. Sure, they might get control of your machine, but there’s no telling what’s on it. So, other than under extraordinary circumstances, they can at best make educated guesses. Put another way, attackers gamble based on their belief of your gross value.

In most cases, it takes far less effort to increase the attacker’s cost than to decrease your gross value. This is why most people will buy security systems for their homes before they give up the big flat-screen TVs. Applying the SDL and increasing the attackers’ costs, therefore, is a great way to protect yourself from those bears out there.

Based on what I said thus far, it’s easy to conclude that very few of us would be potential victims. After all, if you’re not a bank or some similar high-value target, you’re not worth attacking, right? Attackers have a weapon that deflates this argument.

Let’s Make a Deal

In the classic game show Let’s Make a Deal, host Monty Hall gave contestants a choice between keeping an existing prize or trading it for something hidden behind various doors. The contestant had to determine whether it was worth the gamble for an unknown prize.

An attacker would have to do the same, investing the same amount of time on the second victim as on the first, were it not for the magic of amortization. With amortization, an attacker can trade current assets (the investment of time, and maybe some equipment and/or money, to craft the attack) to open not only Door #1, but also Doors #2 through 1,000,000, collecting whatever is behind all of them. It’s an offer no contestant could refuse.

Let’s put this on the graph to see how amortization works.

So let’s assume you are still represented by the green dot, but note your new location. You’re easy to attack, but you’re not really valuable. On Let’s Make a Deal, this would be like giving up the diamond ring for a year’s supply of laundry detergent. Congratulations, you’re in the safe zone, so you don’t need to do anything, right?

Not necessarily. If the vulnerability that you have is shared with others, then the attacker can aggregate all of you at a very small increase in cost. To the attacker, all of the victims aggregate to a single high value at low cost. To the attacker, it’s trading the one diamond ring for a million years’ supply of laundry detergent. The attacker can open a store online to sell the excess and really clean up! Collectively, then, you are represented by the red dot…very high value in aggregate, at a small increase in cost over attacking you alone. So you’re not really in the safe zone at all. You’re deep in the danger zone!

A real world example of this is the use of vulnerabilities in Windows to create botnets. The same vulnerability existed on millions of machines, so even though a single bot is of sufficiently low value as to render the individual machine safe (i.e., where the green dot is), the low additional cost of applying that same attack to millions of machines made the attack worthwhile to an attacker. Collectively, the botnet is represented by the red dot.

But you don’t even need to have exactly the same software across multiple machines in order for amortization to work. An entire class of vulnerability, such as SQL injection, can benefit from amortization. So even if you write your own application, to be used in a single installation, on a singularly low-value machine, you can still find yourself a member of the collective dreaded red dot!

If you’re a member of such a group, increasing the cost to an attacker pays even bigger dividends. By applying the SDL, you can improve your security, pull you out of the group, and therefore move you up the graph. Furthermore, as you increase your differentiation from the herd, you become harder to aggregate, which (from the attacker’s perspective) moves you to the left as well. The rest of the group you left behind can be bear food.

So you can see that it’s not only unnecessary to outrun the bear, but it’s also not necessarily enough to be faster than the other guy. By applying a systematic, thorough approach to security, such as through the SDL, you can become hard enough to attack that you can significantly reduce your risk.