The Security Development Lifecycle : SDL

ATL, MS09-035 and the SDL

sdl — Tue, 28 Jul 2009 20:35:00 GMT

Hello, Michael here.

<updated: 7/31 - changed the compiler 'warning' to 'error'>

Today, the Microsoft Security Response Center (MSRC) released two out-of-band security bulletins, MS09-034 and MS09-035, and a Security Advisory, to address security bugs in the Active Template Library (ATL) and I think it’s appropriate that I explain why the SDL did not find these bugs and what we learned.

I’ve said this many times, but I’ll say it again, because I think it bears repeating. A bug of any kind is an opportunity to learn and then adjust your development practices if appropriate. In this post I will only outline the bugs fixed in ATL, not any of the defense-in-depth mechanisms added to Internet Explorer as part of MS09-034. You can find more information about the IE update in Dave Ross’s blog post at Security Research & Defense.

But before I explain the bugs, I want to spend a couple of minutes to explain ATL. The Active Template Library (ATL) is a set of lightweight C++ classes originally designed to make creating COM objects easier. ATL handles all the object reference counting and handles common COM tasks with ease. But ATL is not restricted to COM; there are classes to handle smart pointers, images, the registry and ACLs and more.

When a developer creates a C++ project in Visual Studio, they are given the option to create an ATL project and if the developer opts to do so, the most important headers are automatically added to the project.

One final point before I discuss the bugs, the ATL source code is available for you to review; in the case of Visual Studio 2008, in the %ProgramFiles%\Microsoft Visual Studio 9.0\vc\atlmfc folder.

Now let’s dig into the bugs.

Bug #1: A Typo!

This is the core issue in the MSVidCtl ActiveX control. The bug is in a modified version of an older version of ATL, and is not in the public ATL code, but in a privately updated version of the ATL code.

Sidebar: How do ActiveX and COM differ?

Skip this section if you want to focus on the core security issues; I added this to answer to a question I get a lot. The Component Object Model (COM) is a binary specification that defines how objects can interact. An ActiveX object is a COM object. The major feature that characterizes ActiveX objects is their ability to be used from scripting languages. Doing so is often called ‘automation’. ActiveX objects use a COM interface named IDispatch which allows the script engine to resolve and call methods in the object at runtime. This is often called ‘late binding.’

The bug is simply a typo, can you spot it? I have removed extraneous code and error checking to make it easier to spot, and removed references to the psa variable (it’s a SAFEARRAYBOUND if you need to know)

__int64 cbSize;
hr = pStream->Read((void*) &cbSize, sizeof(cbSize), NULL);
BYTE *pbArray;
HRESULT hr = SafeArrayAccessData(psa, reinterpret_cast<LPVOID *>(&pbArray));
hr = pStream->Read((void*)&pbArray, (ULONG)cbSize, NULL);

I’ll give you one more clue – it’s a one character typo.

Give up? Look at the last line. The first argument is incorrect. It should be:

hr = pStream->Read((void*)pbArray, (ULONG)cbSize, NULL);

The extra ‘&’ character in the vulnerable code causes the code to write potentially untrusted data, of size cbSize, to the address of the pointer to the array, pbArray, rather than write the data into the array, and the pointer is on the stack. This is a stack-based buffer overrun vulnerability.

I contend that this would be very difficult to spot in a code review, and is not picked up by the C/C++ compiler owing to the (void*) cast. If the cast is removed, the compiler issues an error like this:

C2664: '<function>' : cannot convert parameter 1 from 'BYTE **' to 'BYTE *'

I despise C-style casting because it’s utterly unsafe; C++ casting is safer, although the reinterpret_cast operator is almost as bad as C-style casting.

So why did we miss this?

Our static analysis tools don’t flag this one because the cast tells the compiler and tools, “I know what I’m doing!” I looked over a few dozen instances of casting code like this in various code bases and they were all correct, so adding a rule to flag this kind of code would be prone to false positives and I would not want to subject anyone to a potentially massive amount of noise.

In the SDL we require that teams fuzz their controls, but our fuzzing tools didn’t find this because the method in question requires a specially formed input stream that includes many sentinel bytes. I explain the weaknesses of fuzzing here. We are in the process of adding more heuristics to our fuzzing engine so it can include these COM-specific bytes if needed.

Our banned API removal doesn’t find this because there is no banned API in play.

Some of the defenses such as ASLR and DEP in Windows might come into play, depending on the component in question. That seems like a vague answer, but I say “depending” because ATL is a source code template library that is used to build software, and it is up to the developers to use these defenses. Customers using Internet Explorer 8 on Windows Vista SP1 and later are better protected because ASLR and DEP are enabled by default.

The code is compiled with /GS, but there is no stack cookie for the vulnerable function because there are no local variables to protect, so /GS protection is ineffective in this instance.

Bug #2: Using ATL Property Maps to Instantiate a COM object

ATL allows COM objects to easily persist their properties to a stream of bytes and that byte-stream can then be re-constituted by the object at a later time. ATL does this using a ‘property map.’ The stream can be comprised of a series of tuples. When using tuples, the first portion of the tuple is the data type and, depending on the data type, a size (for example, an n-byte string [VT_BSTR]) and the second portion is the data itself.

If the data type in the stream is VT_DISPATCH or VT_UNKNOWN, then the control might be vulnerable.

The vulnerable code is in the shipping ATL source code, it’s in the CComVariant::ReadFromStream() method.

So how did we miss this? The SDL offers no requirements or recommendations about using ATL property maps; in fact, the SDL offers few practices about hosting COM containers, mainly because there are so few of them, the most well-known COM container is Internet Explorer. We do require that teams use tools to identify their Safe-for-Scripting and Safe-for-Instantiation controls, however.

In theory fuzzing should have found this, but our fuzzing engine does not build the correct stream and the stream is rejected. See the previous bug.

What We’re Doing

I want to point out that this is all very fluid right now owing to our rapid turn-around getting the bulletin out and I want to make sure we do the right thing in the SDL rather than rushing things and getting it wrong.

First and foremost, we are updating our fuzzing tools to help find COM stream-related issues quickly, and we will update the SDL to tell teams to fuzz any COM object they have using any of the risky interfaces (like IPersistStream*, IPersistStorage, etc.)

Second, we’re going to tell teams they must use the new ATL libraries. Today we have a “minimum compiler and linker toolset” requirement, but we don’t explicitly tell people which ATL to use. We’re going to change that!

Finally, I want to drill a little deeper into casting issues. This will be a side project for me over the next few months, as I wade through bug databases and code to see if there are other related issues. I’ll also speak to various static analysis and C/C++ language experts here at Microsoft and across the industry to get their views and insight. If you have a professional opinion on casting issues, please feel free to let me know through this blog.

A Declspec SAL to Attribute SAL Rosetta Stone

sdl — Thu, 11 Jun 2009 20:19:33 GMT

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.

New SDL Pro Network Members: SANS and SAIC

sdl — Thu, 21 May 2009 18:50:00 GMT

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

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

sdl — Fri, 15 May 2009 00:41:00 GMT

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?

The Open Source Quality Challenge

sdl — Fri, 01 May 2009 17:02:00 GMT

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

sdl — Thu, 30 Apr 2009 22:33:00 GMT

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

sdl — Thu, 23 Apr 2009 23:27:00 GMT

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.

MS08-078 and the SDL

sdl — Fri, 19 Dec 2008 04:59:00 GMT

Hi, Michael here.

Every bug is an opportunity to learn, and the security update that fixed the data binding bug that affected Internet Explorer users is no exception.

The Common Vulnerabilities and Exposures (CVE) entry for this bug is CVE-2008-4844.

Before I get started, I want to explain the goals of the SDL and the security work here at Microsoft. The SDL is designed as a multi-layered process to help systemically reduce security vulnerabilities; if one component of the SDL process fails to prevent or catch a bug, then some other component should prevent or catch the bug. The SDL also mandates the use of security defenses whose impact will be reflected in the "mitigations" section of a security bulletin, because we know that no software development process will catch all security bugs. As we have said many times, the goal of the SDL is to "Reduce vulnerabilities, and reduce the severity of what's missed."

In this post, I want to focus on the SDL-required code analysis, code review, fuzzing and compiler and operating system defenses and how they fared.

Background

The bug was an invalid pointer dereference in MSHTML.DLL when the code handles data binding. It's important to point out that there is no heap corruption and there is no heap-based buffer overrun!

When data binding is used, IE creates an object which contains an array of data binding objects. In the code in question, when a data binding object is released, the array length is not correctly updated leading to a function call into freed memory.

The vulnerable code looks a little like this (by the way, the real array name is _aryPXfer, but I figured ArrayOfObjectsFromIE is a little more descriptive for people not in the Internet Explorer team.)

int MaxIdx = ArrayOfObjectsFromIE.Size()-1;

for (int i=0; i <= MaxIdx; i++) {

     if (!ArrayOfObjectsFromIE[i])

           continue;

      ArrayOfObjectsFromIE[i]->TransferFromSource();

      ...

}

Here's how the vulnerability manifests itself: if there are two data transfers with the same identifier (so MaxIdx is 2), and the first transfer updates the length of the ArrayOfObjectsFromIE array when its work was done and releases its data binding object, the loop count would still be whatever MaxIdx was at the start of the loop, 2.

This is a time-of-check-time-of-use (TOCTOU) bug that led to code calling into a freed memory block. The Common Weakness Enumeration (CWE) classification for this vulnerability is CWE-367.

The fix was to check the maximum iteration count on each loop iteration rather than once before the loop starts; this is the correct fix for a TOCTOU bug - move the check as close as possible to the action because, in this case, the array size might change.

Code Analysis and Review

Memory-related TOCTOU bugs are hard to find through code review; we teach TOCTOU issues, and we teach memory corruption issues, and issues with using freed memory blocks; but we do not teach memory-related TOCTOU issues. We will update our training to address this.

Our static analysis tools don't find this because the tools would need to understand the re-entrant nature of the code.

Fuzz Testing

In theory, fuzz testing could find this bug, but today there is no fuzz test case for this code. Triggering the bug would require a fuzzing tool that builds data streams with multiple data binding constructs with the same identifier. Random (or dumb) fuzzing payloads of this data type would probably not trigger the bug, however.

Defenses

There is a plethora of defenses available on various versions of Windows, but only a couple came into play owing to the nature of the code.

-GS

As mandated by the SDL, the code is compiled with -GS to detect some forms of stack-based buffer overruns at runtime, but it's moot because this is not a stack-based buffer overrun.

ASLR and NX

Even though Windows Vista and Windows Server 2008 have both ASLR and NX enabled by default, Internet Explorer 7 does not opt-in to these defenses owing to compatibility issues with many common applications. Internet Explorer 8 enables these defenses by default, but an attack could be mounted by calling a component that does not use these defenses, and then by using an attack technique known as heap-spraying get the attacker's code into the non-ASLR and non-NX memory. This is why it's so important to build components for Windows that use all the available Windows defenses. Matt Thomlinson and I wrote an article on this subject, and David LeBlanc and I wrote Writing Secure Code for Windows Vista that covers the subject in much more detail.

Heap Termination on Corruption

IE7 and IE8 both use the SDL-required process termination if the heap is corrupted (you can read more about this here.) But there is technically no heap corruption, so the defense does not come into play in this instance.

Internet Explorer 7 and 8 Protected Mode

On Windows Vista and Windows Server 2008, this is a major defense that comes into play against the currently circulating exploits. When the exploit code runs, it's running at low integrity because IE runs at low integrity, and this means the exploit code cannot write to higher integrity portions of the operating system, which is just about everywhere!

For our server platforms, Windows Server 2003 and Windows Server 2008, Internet Explorer Enhanced Security Configuration also prevents the exploit from working because the vulnerable code is disabled.

How was the bug found?

We really don't know how the bug was found, but some of the security people in Internet Explorer and the Trustworthy Computing Security teams suggest that the bug was either "stumbled upon" or found through directed fuzzing. The finder could spend as long as he or she wanted to find this one bug. This is one of the things that makes security hard - security is a highly asymmetric problem: software developers must get the code right 100% of the time in a very short amount of time, while attackers can spend as long as they want to find one bug. This isn't an excuse; it's a fact of life

Summary

I think this bug is a great example of "you will never get the code 100% right, so multiple defenses are critical." As you can see from this post, many defenses in Windows did not come into play, but all it takes is one defense to help stop or reduce the chance that an exploit will succeed, and in the case of Windows Vista and Windows Server 2008, Internet Explorer's Protected Mode was that defense.

If there is one other lesson from this, it's that we, the software industry, need to work harder to make sure applications take advantage of the defenses offered in Windows today.

Credits

Big thanks to Chengyun Chu, Jonathan Ness, Adam Shostack, Bronwen Matthews, Mike Reavey and Steve Lipner for their valuable edits and input to this post.

I also want to thank the Internet Explorer team and the Microsoft Security Response Center team for such a rapid turn-around under incredible pressure. A job well done.

Secure Coding Secrets?

sdl — Tue, 18 Nov 2008 22:38:00 GMT

Hi, Michael here.

A recent article titled "NSA posts secrets to writing secure code" caught my eye in part because the words "writing secure code" always get my attention! But also because anything that can advance the science of securing software is of interest to me.

There is another reason why the article got my attention; my manager, Steve Lipner, is one of the few people to have designed and built a TCSEC A1 assured system and lived to tell the tale. None were sold, but they built one!

The NSA-directed project, the Tokeneer ID Station (TIS), involved building a low-defect system that conforms "to the Common Criteria requirements for Evaluation Assurance Level 5 (EAL5)" in a "cost effective manner." I'm all for this, because building high-assurance solutions is not cheap.

There's a paper with more technical detail about the project that is worth a read.

In my opinion, the project is only a science project, an experiment, for the following reasons:

It's tiny. Weighing in at a little under 10 KLOC.
It's only a very small portion of a much larger solution which has not been developed using the same rigor. This bit of context makes the solution as a whole moot. Call me cynical, but my question is "can the entire solution be built with same rigor in a ‘cost effective manner'?" Perhaps it can, but that is not what is presented.
It sits on top of many operating systems (Windows, Mac OS X and Linux) that are not EAL5 certified. So it would be a little like having an EAL5 certified CharMap application running on EAL4 Windows Vista.
It's written in a subset of Ada called SPARK, and SPARK skills are not common in the marketplace. Interestingly, SPARK makes use of annotations to help drive the static analysis process. While not a total analog, we also recommend Microsoft development teams use annotations (SAL) to help drive the required static analysis process.
The application has a large number of dependencies that are not part of the project:

Directory of C:\tokeneer\data

18/08/2007 08:51 605,333     libgdk-win32-2.0-0.dll
18/08/2007 08:51 166,177     libgdk_pixbuf-2.0-0.dll
17/08/2007 18:07 642,115     libglib-2.0-0.dll
17/08/2007 18:07 28,853      libgmodule-2.0-0.dll
17/08/2007 18:07 223,026     libgobject-2.0-0.dll
18/08/2007 08:52 3,170,609   libgtk-win32-2.0-0.dll
08/08/2008 16:32 4,868,618   libgtkada-2.10.dll
07/04/2004 11:47 44,100      libintl-1.dll
17/08/2007 18:29 522,940    libcairo-2.dll
17/08/2007 18:36 262,784    libpango-1.0-0.dll
17/08/2007 18:36 62,334      libpangocairo-1.0-0.dll
17/08/2007 18:37 88,626      libpangowin32-1.0-0.dll
07/10/2001 01:52 171,008     libpng-3.dll
07/04/2004 11:46 58,077     libz.dll
07/04/2004 11:47 843,776     iconv.dll
17/08/2007 18:22 142,762    libatk-1.0-0.dll
16/01/2007 12:27 131,784     libjpeg6b.dll

In the SDL we call these files ‘giblets' because they are components needed for your application to operate, but they do not belong to your team. Some of the files look old and highly vulnerable, such as libpng-3.dll from 2001! OSVDB lists 23 vulnerabilities since 2002 in libpng!

In summary, the TIS project is very interesting to a small number of important but specialized customers, such as the NSA, for whom this kind of research is critical. I too found it interesting, but the process is far from a set of "secrets to writing secure code" and the tools are certainly not within reach of day-to-day applications and not applicable to developing complete solutions.

As usual, all comments are very welcome.

MS08-067 and the SDL

sdl — Thu, 23 Oct 2008 04:09:00 GMT

Hi, Michael here.

No doubt you are aware of the out-of-band security bulletin issued by the Microsoft Security Response Center today, and like all security vulnerabilities, this is a vulnerability we can learn from and, if necessary, can use to shape future versions of the Security Development Lifecycle (SDL).

Before I get into some of the details, it's important to understand that the SDL is designed as a multi-pronged security process to help systemically reduce security vulnerabilities. In theory, if one facet of the SDL process fails to prevent or catch a bug, then some other facet should prevent or catch the bug. The SDL also mandates the use of security defenses, because we know full well that the SDL process will never catch all security bugs. As we have said many times, the goal of the SDL is to "Reduce vulnerabilities, and reduce the severity of what's missed."

In this post, I want to focus on the SDL-required code analysis, code review, fuzzing and compiler and operating system defenses and how they fared.

Code Analysis and Review

I want to start by analyzing the code to understand why we did not find this bug through manual code review nor through the use of our static analysis tools. First, the code in question is reasonably complex code to canonicalize path names; for example, strip out ‘..' characters and such to arrive at the simplest possible directory name. The bug is a stack-based buffer overflow inside a loop; finding buffer overruns in loops, especially complex loops, is difficult to detect with a high degree of probability without producing many false positives. At a later date I will publish more of the source code for the function.

The loop inside the function walks along an incoming string to determine if a character in the path might be a dot, dot-dot, slash or backslash and if it is then applies canonicalization algorithms.

The irony of the bug is it occurs while calling a bounded function call:

_tcscpy_s(previousLastSlash, pBufferEnd - previousLastSlash, ptr + 2);

This function is a macro that expands to wcscpy_s(dest, len, source); technically, the bug is not in the call to wcscpy_s, but it's in the way the arguments are calculated. As I alluded to, all three arguments are highly dynamic and constantly updated within the while() loop. There is a great deal of pointer arithmetic in this loop. Without going into all the gory attack details, given a specific path, and after the while() loop has been passed through a few times, the pointer, previousLastSlash, gets clobbered.

In my opinion, hand reviewing this code and successfully finding this bug would require a great deal of skill and luck. So what about tools? It's very difficult to design an algorithm which can analyze C or C++ code for these sorts of errors. The possible variable states grows very, very quickly. It's even more difficult to take such algorithms and scale them to non-trivial code bases. This is made more complex as the function accepts a highly variable argument, it's not like the argument is the value 1, 2 or 3! Our present toolset does not catch this bug.

Ok, now I'm really going out on a limb with this next section.

Over the last year or so I've noticed that the security vulnerabilities across Microsoft, but most noticeably in Windows have become bugs of a class I call "onesey - twosies" in other words, one-off bugs. There is a good side and a bad side to this. First the good news; I think perhaps we have removed a good number of the low-hanging security vulnerabilities from many of our products, especially the newer code. The bad news is, we'll continue to have vulnerabilities because you cannot train a developer to hunt for unique bugs, and creating tools to find such bugs is also hard to do without incurring an incredible volume of false positives. With all that said, I will add detail about one-off bugs to our internal education; I think it's important to make people aware that even with great tools and great security-savvy engineers, there are still bugs that are very hard to find.

Fuzz Testing

I'll be blunt; our fuzz tests did not catch this and they should have. So we are going back to our fuzzing algorithms and libraries to update them accordingly. For what it's worth, we constantly update our fuzz testing heuristics and rules, so this bug is not unique.

Defenses

If you want the full details of the defenses, and how they come into play on Windows Vista and Windows Server 2008, I urge you to read the SVRD team's in-depth analysis once it is posted.

A big focus of the SDL is to define and require defenses because we have no illusions about finding or preventing all security vulnerabilities by attempting to get the code right all the time, because no-one can do that. No one. See my comment above about one-off bugs!

Let's look at each SDL mandated requirement and how they fared in light of this vulnerability.

-GS

The -GS story is not so simple. A lot of code is executed before a cookie check is made and the attacker can control the overflow because the overflow starts at an offset before the stack buffer, rather than at the stack buffer itself. So the attacker can overwrite other frames on the call stack, corresponding to functions that return before a cookie check is made. That's a long way of saying that -GS was not meant to prevent this type of scenario.

ASLR and NX

The code fully complies with the SDL, and is linked with /DYNAMICBASE and /NXCOMPAT on Windows Vista and Windows Server 2008. There are great defenses when used together, and reduce the chance of a successful attack substantially. Also, the stack offset is randomized too, making a deterministic attack even more unlikely.

Service Restart Policy

By default the affected service is marked to restart only twice after a crash on Windows Vista and Windows Server 2008, which means the attacker has only two attempts to get the attack right. Prior to Windows Vista, the attacker has unlimited attempts because the service restarts indefinitely.

Authentication

Thanks to mandatory integrity control (MIC) settings (which comes courtesy of UAC) the networking endpoint that leads to the vulnerable code requires authentication on Windows Vista and Windows Server 2008 by default. Prior to Windows Vista, the end point is always anonymous, so anyone can attack it, so long as the attacker can traverse the firewall. This is a great example of SDL's focus on attack surface reduction; requiring authentication means the number of attackers that can access the entry point is dramatically reduced.

Firewall

We enabled the firewall by default in Windows XP SP2 and later, this was a direct learning from the Blaster worm. By default, ports 139 and 445 are not opened to the Internet on Windows XP SP2, Windows Vista and Windows Server 2008.

Summary

The $64,000 question we ask ourselves when we issue any bulletin is "did SDL fail?" and the answer in this case is categorically "No!" No because as I said earlier the goal of the SDL is "Reduce vulnerabilities, and reduce the severity of what you miss." Windows Vista and Windows Server 2008 customers are protected by the defenses in the operating system that have been crafted in part by the SDL. The development team who built the affected component compiled and linked with the appropriate settings as described in "Windows Vista ISV Security" and Writing Secure Code for Windows Vista so that their service is protected by the operating system.

The team did not poke holes through the firewall unnecessarily, in accordance with the SDL.

The team reduced their attack surface, in accordance with the SDL, by requiring authenticated connections rather than anonymous connections by default.

We know that the SDL-mandated -GS has very strict heuristics so some functions are not protected by a stack cookie, but in this case, there is no buffer on the stack, so there will be no cookie. We know this. There are no plans to remedy this in the short term.

Fuzzing missed the bug, so we will update our fuzz testing heuristics, but we continually update our fuzzing heuristics anyway.

In short, based on what we know right now, Windows Vista and Windows Server 2008 customers are protected because of the SDL-mandated defenses in the operating system, and because the development team adhered to the letter of the SDL to take advantage of those defenses.

Chalk one up for Windows Vista and later and the SDL!

As usual, questions and comments are very welcome.

Good hygiene and Banned APIs

sdl — Thu, 23 Oct 2008 01:08:00 GMT

Jeremy Dallman here with a quick note about a code sanitizing tool we are making available to support one of the SDL requirements – Remove all Banned APIs from your code.

This requirement was put in place to prevent use of certain older C runtime functions that lead to buffer overrun flaws and have been deprecated. In the Security Development Lifecycle book, an entire chapter is dedicated to the topic of banned function calls. In the book, we also provide a copy of the banned.h header file on the companion CD. This header file allows you to locate any banned functions in your code.

On MSDN, we have document the SDL list of Banned Function Calls, but the header file has not been publicly available outside the SDL book until now. Today, we are providing the banned.h header on the Microsoft Download Center.

Find the banned.h header here

By including this header file, then using #include “banned.h”; you will be able to locate any banned functions in your code. The full list of banned APIs is also included in the header file.

Alternately, if you are using the compiler in Visual Studio 2005 or later, you have a built-in way to check for these banned functions. To catch banned C runtime functions, you can compile with /W4 and then triage all C4996 warnings. In code reviews, you should always remove any code that disables the C4996 warnings - e.g.: #pragma warning(disable:4996). This is one simple way to ensure your code is released without banned functions.

Sanitizing your code to remove potentially insecure APIs is a vital protection. Whether you include the banned.h header file or leverage the /W4-C4996 warnings in the Visual Studio 2005 compiler, you now have two ways to check your code and meet another SDL requirement in your development phase.

Security is bigger than finding and fixing bugs

sdl — Thu, 14 Aug 2008 23:09:00 GMT

I’ve been catching up on various security-related articles that I’ve been meaning to read, and the following article was on the list http://www.itnews.com.au/News/73635,google-shares-its-security-secrets.aspx about Google’s “security secrets.”

Quoting from the article:

“In order to keep its products safe, Google has adopted a philosophy of 'security as a cultural value'. The programme includes mandatory security training for developers, a set of in-house security libraries, and code reviews both by Google developers and outside security researchers."

I think it is great that Google has a security program they are willing to talk about and I could not agree more with the ‘security as a cultural value’ philosophy. But isn’t there something really fundamental missing here? Design? There is a lot more to software engineering other than coding and testing.

The SDL has a very large set of implementation-related requirements, but there are many design-related requirements also.

Computer security experts have known since the early 1970s that you have to get the design right; and our experiences with the SDL over the last 5 years have taught us that you need to consider security and privacy (but remember, you have to ship too!) very early in the design phase and have a consistent end-to-end process if you truly hope to reduce vulnerabilities and create more secure software. This is how the SDL is helping to create ‘security as a cultural value’ at Microsoft.

We’ve seen a general trend downward in security vulnerabilities in Microsoft products, and the IBM X-Force 2008 mid-year report backs the assertion that we’re making progress; according to the report Microsoft’s share of total vulnerabilities decreased from 3.7% in 2007 (1st place) to 2.5% (that’s 2.5% for all Microsoft products; a more appropriate comparison might be Windows vs Linux vs Mac OSX, or SQL Server vs Oracle vs DB2) in the first 6 months of 2008 (3rd place.) This is an encouraging signal that the SDL is working on a large scale… of course, it might also show that vulnerability researchers are moving to easier targets, which, to me shows the SDL is working too.

What do you think?

Improve Security with "A Layer of Hurt"

sdl — Thu, 31 Jul 2008 22:13:00 GMT

Hello, Michael here.

I got a lot of interesting comments from my TechEd 2008 presentation entitled, "How To Review Your Code And Test For Security Bugs," but the most comments and questions were reserved for fuzz testing; I was blown away by the number of people who thought fuzz testing was hard, or that you only left fuzz testing to ‘leet hackers.

During the presentation I mentioned in some depth how to perform fuzz testing, and what parts of an application should be fuzz testing targets. I also introduced an idea (that's not new) to help people who have never performed fuzz testing begin fuzz testing with very little cost and friction. The idea is to add a small layer of code to an application to automatically mutate untrusted data as it comes into an application; I called that code layer "a layer of hurt."

Before I continue, I want to point out that fuzzing is an SDL requirement, but the idea in this blog post is not an SDL requirement, it's just another way to help meet SDL fuzzing requirements.

Adding a layer of hurt, as shown in the picture below, is pretty simple as it involves adding code to an application to tweak data as it comes into an application. You can work out where to place the fuzzing code by looking at your threat models to see where data crosses trust boundaries. You could also simply grep the code looking for APIs that read data, for example:

Read from files: fread, ReadFile
Reading from sockets: recv, recvfrom
For .NET code, any stream.Read

You get the picture.

The fuzzing code should appear right after the API that reads that data.

For example, C or C++ code that reads from a UDP socket and then fuzzes the data before it's consumed by the rest of the application might look like this:

char RecvBuf[1024];
int BufLen = sizeof(RecvBuf);

int result = recvfrom(
   RecvSocket,
   RecvBuf,
   BufLen,
   0,
   (SOCKADDR *)&SenderAddr,
   &SenderAddrSize);

#ifdef _FUZZ
Fuzz(RecvBuf,&BufLen);
#endif

Or, in C#, code that reads from an untrusted file:

FileStream fileStream = new FileStream(filename, FileMode.Open, FileAccess.Read);
uint len = (uint)(fileStream.Length);
byte[] fileData = new byte[fileStream.Length];
fileStream.Read(fileData, 0, (int)len);
fileStream.Close();

#if _FUZZ_
Malform pain = new Malform();
fileData = pain.Fuzz(fileData);
#endif

In both code examples, Fuzz() mutates the incoming data. In the C++ case, the fuzzing code looks like this:

void Fuzz(_Inout_bytecap_(*pcbBuf) char *pBuf,
_Inout_ size_t *pcbBuf) {

if (!pcbBuf || !pBuf || !*pcbBuff || *pBuf) return;
if ((rand() % 100) > 5) return; // fuzz about 5% of Buffers

size_t cLoop = 1 + (rand() % 4);

for (size_t j = 0; j < cLoop; j++) {

    size_t i=0,
      iLow = rand() % *pcbBuf,
      iHigh = 1+rand() % *pcbBuf,
      iIter = 1+rand() % 8;

    if (iLow > iHigh)
      {size_t t=iHigh; iHigh=iLow; iLow=t;}

char ch=0;
switch(rand() % 9) {

      case 0 : // reset upper bits
        for (i=iLow; i < iHigh; i++)
          pBuf[i] &= 0x7F;
        break;

      case 1 : // set upper bits
        for (i=iLow; i < iHigh; i++)
          pBuf[i] |= 0x80;
        break;

      case 2 : // toggle all bits
        for (i=iLow; i < iHigh; i++)
          pBuf[i] ^= 0xFF;
        break;

      case 3 : // set to random chars
        for (i=iLow; i < iHigh; i++)
          pBuf[i] = (char)(rand() % 256);
        break;

      case 4 : // set NULL chars to (possibly) non-NULL
        for (i=iLow; i < iHigh; i++)
          if (!pBuf[i])
            pBuf[i] = (char)(rand() % 256);
        break;

      case 5 : // swap adjacent bytes
        for (i=iLow; i < __max(iHigh-1,iLow); i+= iIter)
          {char t=pBuf[i]; pBuf[i] = pBuf[i+1]; pBuf[i+1]=t;}
        break;

      case 6 : // set to random chars every n-bytes
        for (i=iLow; i < __max(iHigh-1,iLow); i+= iIter)
          pBuf[i] = (char)(rand()%256);
        break;

      case 7 : // set bytes to one random char
        ch=(char)(rand() % 256);
          for (i=iLow; i < iHigh; i++)
            pBuf[i] = ch;
        break;

      default: // truncate stream
        *pcbBuf = iHigh;
        break;
     }
   }
}

The sample C# and C++ fuzzing code is available as a ZIP file at the end of this post.

This code is an example of dumb-fuzzing, which is fuzzing with little or no regard for the data structure being manipulated. If you've never performed any kind of fuzz testing in the past, then you will probably find bugs with this simple fuzzing technique. Once you have weeded out the low-hanging bugs, you may need to turn your attention to smarter fuzzers. For example, in theory, this code would find few if any bugs in a PNG parser, because PNG files have a built in check-sum, so if you fuzz a PNG file, you'd have to recalculate the checksum to get decent code coverage.

When I showed this code during my presentation, I urged people to add it to their applications today if they currently don't do fuzz testing, and simply run their applications through their normal testing processes. Within three days of my presentation I received emails from people saying they had found bugs. I have no doubt others did too.

One of the comments I made during the session was,"If you can't spend the time on great fuzzing, fuzz anyway" and adding a "layer of hurt" is a reasonable start.

Please feel free to sound off if you have ideas to help improve the code and let us know what you think, either through email or comments to this post.

Wrapping up "Walking" with the SDL

sdl — Wed, 30 Jul 2008 22:16:00 GMT

Jeremy Dallman here. Before we move on with our regularly-scheduled programming here at the SDL blog, I wanted to pull all of the “Walking with the SDL” blog posts into a single document to put it all together in another format. You can find that document here.

Hopefully the “Walking with the SDL” series provided some valuable guidance that will help you formalize your own Security Development Lifecycle. As always, we welcome your thoughts or questions in the COMMENT section of this blog. If you have specific questions that you would like to discuss with our team, you can use the EMAIL link at the top of the blog and we’ll be sure to reply.

"Walking" with the SDL - Part 4

sdl — Fri, 25 Jul 2008 23:49:00 GMT

Jeremy Dallman here with the final piece of my multi-part series on “Walking” with the Security Development Lifecycle (SDL) [Part 1, Part 2, Part 3]. So far I have discussed getting management approval, expanding security training, formalizing security requirements and effective ways to reuse your threat model or attack surface review data. In this post, I will wrap up with a look into setting up final security reviews and managing post-release documentation.

Formalize your Final Security Review (FSR) Process

A Final Security Review is your final security audit to ensure your software is secure enough to deliver to your customers. I will assume the idea of an FSR is a new concept and try to provide some FAQ-style detail on this topic.

Who is the FSR team? An FSR Team usually consists of a non-product-team security expert (for impartial perspective), a security representative from the product team, and individual representatives from the separate disciplines. However, that size team may not scale to your company. If that is the case, at a minimum, you should have an impartial “outsider” separate from the product team who understands the security requirements as well as the measurements used to validate them. This person along with a project manager can probably perform the bulk of the FSR with development or test leadership providing input as needed.

What is needed to do an FSR? All threat models should be revised to reflect the final product, the code should be complete, and all security-related testing should be completed and documented. In addition, everyone involved in the FSR should have full access to the bug database to review status or exceptions to security bugs.

What does an FSR team do?

Re-review threat models to verify all mitigations identified in those exercises were fixed or went through an exception process.
Verify that all security issues uncovered during the development process were fixed or granted exceptions by the appropriate people. This is where you verify whether the state of your security bugs meets the “bug bar” requirements you have defined for your products.
If there is any output from security tools that you have used to define requirements, the FSR team would verify that the results of the tools meet the security requirements.
Review all exceptions to verify that they approve these decisions in the context of the final product. If they identify risks associated with the exceptions, they should communicate those to the business ownership for a final decision before signoff. Any decisions related to known risks should also be reflected in the response plan for future reference.
Finally, there should be a final signoff exercise where all security people and project leadership jointly approve the decision of the Final Security Review.

How long does an FSR take? If done correctly, the FSR will likely take some time. You should schedule this review well in advance of your release date to give your FSR team some time to complete the review, push issues back to the product team, and respond to any serious issues that may be discovered.

Final security reviews are a crucial piece to your Security Development Lifecycle. It would be easy to encourage secure development in your team, but as you expand your process to include formal security requirements and begin enforcing those requirements, it is necessary to perform a final audit of your product before it is released. Your customers will thank you for taking the time to add this layer of quality control to your operations and you will likely save yourself some security embarrassment down the road by adding a FSR to the end of your product cycle.

Document security work for reference

After the FSR is complete, there is still work for the security team. The final FSR documentation should be archived along with the symbols and code that represents the finished project. This becomes the time-stamped “snapshot” of your product. Your post-release process should include archiving the following documents in an easily accessible location:

· All final threat models for future reference.

· Bug bars, tool settings, and test results related to your project and the supporting tools used to validate. These will be referenced and reused in the next product cycle.

· All documented security bug exceptions. These need to be rolled into your next product cycle to ensure they are addressed.

· The final symbols that reflect the product shipped should be archived.

· The Final Security Report and project signoffs to validate your security audit activity

· Your Incident Response Plan (discussed in the Crawl post). This must be accessible for quick reference if security incidents occur.

Archiving this evidence serves a few critical purposes: it shows historic evidence of the work you did to ensure a secure product, allows you to postmortem the results and improves your process each time, and reduces the amount of time your team will have to spend next time around by making the existing resources reusable.

In closing…

I hope this long series has provided some practical steps you can take to move your Security Development Lifecycle practices to the next level. At Microsoft, creating a lifecycle to match security development practices has faced a fair share of challenges. However, the investment and time has resulted in more secure products. We’ll continue refining how we execute the Security Development Lifecycle and hope to share those ideas with you along the way. We welcome your thoughts and questions as you start “Walking” with the SDL in your own company and look forward to seeing more secure products and customers as a result.

I’ve created a unique tag on the SDL Blog to cover this series. To get a full list of the related posts, click the “Crawl Walk Run” tag on the left column. I’ll post a Word document version of the full “Walk” series sometime in the next week.