The Security Development Lifecycle

SDL at TechEd Europe and Platforma

sdl — Thu, 05 Nov 2009 21:05:00 GMT

Hi everyone, Bryan here. I’m going to be presenting two sessions on the SDL next week, one for TechEd Europe and one for the Microsoft Platforma event in Moscow. If you’re attending either of these conferences, stop by and introduce yourself, or better yet stay for the session!

TechEd Europe:

SIA-205: SDL-Agile: Microsoft’s Approach to Security for Agile Projects

Monday 11/9 9:00-10:15, Berlin 1 Hall 7-3a

Platforma:

FF-206: The Microsoft Security Development Lifecycle

Thursday 11/12 4:30-5:30, Red Congress-Hall

Hope to see you there!

SIR Volume 7 Released

sdl — Wed, 04 Nov 2009 16:16:38 GMT

Hi everyone, Bryan here. Earlier this week, Microsoft released the latest volume of the Security Intelligence Report (SIR), which covers the first half of 2009. There are many interesting statistics in this report, but there’s one that I’d like to draw particular attention to: the number of industry-wide reported vulnerabilities as broken down by OS vulns vs. browser vulns vs. application vulns.

It is gratifying to see a sharp decline in the number of application vulnerabilities reported in the first half of 2009, but it’s important to note that they still make up the vast majority of vulns. Attackers are still largely focusing on the long tail of third-party applications. It’s more important than ever for all development shops, no matter how small, to bake security practices into their development lifecycles and ensure that their products don’t end up contributing to next year’s blue Application Vulnerabilities bar.

Ninjas are cool, but engineers build bridges

sdl — Fri, 23 Oct 2009 18:20:05 GMT

Cory at Matasano has a new blog post explaining “Ninja threat modeling.” Ninja threat modeling is Matasano’s approach to threat modeling as part of a penetration test. I’m really happy that they’ve given their approach a name. A few years back, we would just talk about “threat modeling” and it got confusing. With that said, Adam here, and I wanted to offer up our perspective. I’ll do that by first comparing and contrasting the SDL and ninja approaches, and then respond to on some Cory’s impressions of the STRIDE-per-Element approach to threat modeling which we’re using in the SDL.

Pirates are Way Cooler than Ninjas, but Engineering Got us to the Moon

There’s a lot to be said for giving your approach a cool name, and we love cool names too, like “The SDL Threat Modeling Tool.” How cool is that? Ok, ninja is much cooler. It seems from Cory’s post that Matasano’s customers are coming to them for security at the end of their process, rather than at the start. I think we all agree that threat modeling late produces less value. Here at Microsoft, we’ve invested in making it possible for any software engineer to threat model at the start of development. We’ve made enough progress in this that Forrester has said “Many application architects and developers don’t know enough about developing secure applications… Microsoft’s SDL Threat Modeling Tool is a unique new tool that helps developers identify and mitigate security risks to make applications more secure from the get-go.” (“Use Threat Modeling To Develop More-Secure Applications,” March, 2009.)

I do think that we can map between the current SDL approach and the Ninja approach:

Stage	STRIDE/Element	Ninja
Model	DFD	App overview, data flow
Identify Threats	STRIDE/Element	Assumptions, deadly sins
Mitigate	Redesign/standard/custom/accepted	?
Validate	Check model, all threats have bugs	Test plan

For a summary of their process, I looked at the boxed text “Ninja threat modeling at a glance.” I wish Cory had explained the approach a bit more: what’s the difference between an app overview and a data flow? Why are there 2 threat enumeration checklists (assumptions, deadly sins)? I think it might be interesting to combine the two threat enumerations. I also think that the risk management step could be formalized a bit more.

So I’m glad that Matasano has a way to help you if you haven’t threat modeled. Our experience and observations over many, many years has shown that most people don’t want (or haven’t budgeted for) ninjas to drop into their process and slice up their design at the last minute. That’s why we’ve been sharing the SDL optimization model, building out the SDL Pro Network and sharing our approaches. We think that most people want to engineer a good and secure product from the start. We all need to work to make that easier, more predictable, and more effective. I also recognize that many organizations are not building security into their development processes yet. So it’s great to see Matasano think through what a threat model at the end of the dev process should look like, and share that thinking.

I wanted to reply to one thing that Cory said:

“It has spawned not just one, but two, Visio-driven toolsets from Microsoft and countless data-flow diagrams, attack trees, consulting engagements, and perplexed developers. When performed by a skilled and experienced team member, the model can be used to identify architectural weaknesses, guide default application behavior, and outline functional requirements for the product.”

Cory’s right. We have two tools, and it’s confusing. We’ll be making that much clearer soon. Additionally, we’ve presented a lot of information about our many approaches over the years.Today, we have one authoritative site at microsoft.com/sdl which presents the most current guidance. We no longer use attack trees. We’re working hard to speak clearly. Is it working for you? Let us know what’s not clear. Yes, there are a lot of books and what-have-you that can’t be updated, but we aim to publish and maintain guidance on the SDL portal that is authoritative, current, and understandable. Kicking attack trees is sort of like commenting on the security of Win98: we’ve learned a lot since then.

One of the most important things we’ve learned is that we needed to simplify the model, the approach, and the training, and we’ve done all three of those things. Having done those things, we’ve seen non-experts pick up the tool and create good threat models. We’ve heard from partners who are using the tool successfully, and we’ve received great feedback from analysts about efforts. None of which means we’re perfect. We’re still continuing to innovate with the aim of making the process better, and seeking the feedback from anyone who’s downloaded and applied our free tools and guidance. We’ve got some tricks up our sleeve, and while we don’t want to play them too close to the chest, we’re going to continue to innovate, and are glad to see a profusion of ideas for making things better. Finally, we work to share our experience.

Ninjas and Engineers Agree: Threat Model

We’ve seen the STRIDE-per-element approach work for non-experts. We suggest you give it a try. But far more important than which approach you try is when you try it. Start early. Take a look at the optimization model. If you want some consulting help, go to one of our Pro Network partners or even to Matasano. If you have a few hours, experiment with both approaches and see which fits. But start early and find a threat modeling approach that helps you deliver more secure software.

Pirates and script kiddies would prefer you just fuzzed.

MS09-050, SMBv2 and the SDL

sdl — Thu, 15 Oct 2009 21:19:00 GMT

10/20/2009: Updated with correct CVE - thanks to Matthieu Suiche for pointing this out to me.

Hi, Michael here.

When I wrote the first analysis of why the SDL had missed a security vulnerability, I made a comment that I would continue to write these posts, but only for bugs that interested me. To be honest, all security bugs interest me, but this one really got me to sit up because it’s in new code.

For reference, the security update that fixes this is MS09-050, and the bug is CVE-2009-3103.

What makes the bug of concern is it’s in networking code; thankfully, there are some mitigations available, such as the Windows Firewall, that reduce exposure to attacks.

First, let’s take a look at the vulnerable code. Can you spot the bug?

#define Smb2GetWorkItem( WI ) ((PSMB2_WORK_ITEM)(WI->ProviderWorkItem))

...

typedef struct _SRV_WORK_ITEM

...

//

    // This is the Receive Buffer for the incoming request

//

    PSRVBUFFER ReceiveBuffer;

    PSRVBUFFER ResponseBuffer;

...

} SRV_WORK_ITEM, *PSRV_WORK_ITEM;

...

NTSTATUS

Smb2ValidateProviderCallback( PSRV_WORK_ITEM WorkItem )

    PSMB2_HEADER pHeader = (PSMB2_HEADER)WorkItem->ReceiveBuffer->Buffer;

    PSMB2_WORK_ITEM pWI = Smb2GetWorkItem( WorkItem );

    PSMB2_CONNECTION pC = Smb2GetConnection( WorkItem->Connection );

    NTSTATUS status;

    pWI->ParentWorkItem = WorkItem;

    pWI->AsyncId = RFSTABLE64_INVALID_ITEM;

    WorkItem->ProviderWorkItemCleanupRoutine = Smb2CleanupWorkItem;

...

    if( pHeader->ProtocolId != SMB2_PROTOCOL_ID )

        if( pHeader->ProtocolId == SMB_PROTOCOL_ID &&

            pC->Dialect == 0xFFFF )

//

            // Handle downlevel multi-negotiate

//

            pWI->Command = SMB2_0_COMMAND_NEGOTIATE;

            goto process_packet;

        else

            WorkItem->DisconnectConnection = TRUE;

            return STATUS_INVALID_PARAMETER;

    pWI->Command = pHeader->Command;

...

process_packet:

    if( SRVWPP_LOG_MESSAGE( DEBUG_MODULE_SRV2, DEBUG_PERF ) )

        Smb2OutputWorkItemRequest( WorkItem );

    if( ValidateRoutines[pHeader->Command ] == NULL )

        return Smb2ValidateNotImplemented( WorkItem );

    else

        return (ValidateRoutines[pHeader->Command])( WorkItem );

If you can’t see the bug, here’s the fix:

    if( SRVWPP_LOG_MESSAGE( DEBUG_MODULE_SRV2, DEBUG_PERF ) )
    {
        Smb2OutputWorkItemRequest( WorkItem );
    }

    if( ValidateRoutines[pWI->Command] == NULL )
    {
        return Smb2ValidateNotImplemented( WorkItem );
    }
    else
    {
        return (ValidateRoutines[pWI->Command])( WorkItem );
    }
}

Look at the two array references to ValidateRoutines[] near the end, the array index to both is the wrong variable: pHeader->Command should be pWI->Command.

So why did the SDL miss this bug?

There is only one current SDL requirement or recommendation that could potentially find this, and that is fuzz testing. In fact we did find it very late in the Windows 7 development process through network fuzzing and that is why post-RC versions of Windows 7 do not have this bug.

Right now there is no static analysis tool I know of that would point out the developer used the wrong variable, and our analysis tools didn’t spot the potential array bounds problem in part because it’s hard to do so with generate a very large quantity of false positives. With that said, we’re looking deeper into the latter challenge now.

The only other method that could find this kind of bug is very slow and painstaking code review. This code was peer-reviewed prior to check-in into Windows Vista; but the bug was missed. Humans are fallible, after all.

Some years ago I created a “How to review code for Security Bugs” class and toward the end I explain that code reviewers need to question all coding logic assumptions when the code deals with untrusted data; I will add a new bullet point: are the correct variables used?

Going Out on a Limb!

I’ve mentioned this before, but it’s worth mentioning again. I think we’re getting to a stage at Microsoft where the SDL has whittled away most of the ‘low-hanging’ bugs. Of course, I might be proven wrong, but looking at all the bugs over the last year in Windows, the only pattern I can spot is there is no pattern! The majority of the bugs I see in Windows are one-off bugs that can’t be found easily through static analysis or education, which leaves only manual code review, and for some bug classes, fuzz testing. But fuzz testing is hardly perfect, because the malformed data might not hit the vulnerable code path or trigger a failure in the code.

I would say that this is a great argument for software developers spending more time on defenses against unknown vulnerabilities, as well as trying to prevent or remove vulnerabilities. The SDL mantra of “Reduce the number of vulnerabilities and reduce the severity of the bugs you miss” is very consistent with this belief.

- Michael

luv u kim x

Cross-Domain Security

sdl — Tue, 13 Oct 2009 00:02:00 GMT

Hi everyone, Bryan here. Peleus Uhley, Senior Security Researcher at Adobe, has written a guest post for the BlueHat blog on potential security issues with cross-domain access permissions for web sites. I’d like to encourage you to read Peleus’ post and also to expand on it a little to talk about the SDL requirements around cross-domain access.

Normally, the Same Origin Policy prevents web pages from interacting with resources hosted on domains other than the one they were loaded from. This is done for security reasons; without the SOP it would be trivial for malicious sites to steal or alter data on other sites. However, there are so many great legitimate uses for cross-domain access (like creating client-side mashups) that several technologies have been developed to allow it under limited, opt-in circumstances. These technologies include:

· Flash’s crossdomain.xml policy file, also used by Silverlight

· Silverlight’s clientaccesspolicy.xml policy file

· IE8 XDomainRequest object

· XMLHttpRequest Level 2 Access-Control headers

· JavaScript document.domain property redefinition

Now, there’s nothing inherently wrong with any of these (although I have argued in the past that cross-domain XMLHttpRequest would destroy the internet). The problem with using these is that it’s easy to inadvertently expose data to sites you don’t intend to expose data to. Using wildcard domains when determining which domains have access permissions exacerbates this problem. The canonical example of this (no pun intended) is the crossdomain.xml setting

<allow-access-from domain="*"/>

This setting basically opens the web site up to cross-domain access from the entire internet.

To help prevent sites from unintentionally exposing data to malicious external domains, the SDL requires any site with authenticated access to enumerate the specific domains it is allowing access to – no wildcards allowed. Otherwise, the site is free to make its cross-domain access as permissive as desired.

The original draft of the SDL cross-domain requirement was slightly different. Initially, the requirement included restrictions on the use of wildcards based on the depth of the wildcard (i.e. two-dots vs. one-dot vs. no-dots) and whether or not the site provided a “private API”. If a site contained only completely public resources, then it was allowed to use wildcards at the two-dots level or greater; for example, *.live.com would be allowed (two dots) but *.com would not (one dot). If a site had any resources only accessible by authenticated users, then no wildcards were allowed; all domains with cross-domain privileges had to be explicitly enumerated in the appropriate policy file or header.

However, we later realized that this requirement draft was both overly complicated and overly restrictive. If a site is completely public – no authenticated access, no private or sensitive data – then there’s really no reason to restrict its access at all. The reason for this is that cross-domain attacks are luring attacks. To succeed, the attacker needs to lure a victim into performing some action on the attacker’s behalf. For example, a cross-domain attack against a stock trading web site might cause the victim to send the attacker the complete details of his stock portfolio, or might cause the victim to make unintended trades. But in a completely public site, there’s no personal data to steal and no possible authenticated actions to forge. There’s no reason for an attacker to perform a luring attack – they already have the same access to the same data that everyone else has.

When we realized that our requirement was too restrictive, we changed it to its current form. However, let’s re-examine the requirement in light of Peleus’ research on cross-domain access chaining. (To give an extremely brief summary for those who haven’t read it yet: cross-domain permissions are transitive. If site A grants privileges to site B, and site B grants privileges to site C, then site A is implicitly and perhaps unknowingly granting privileges to site C.) For the completely public site the potential of privilege chaining is a non-issue in terms of SDL requirements; we’ve already said it’s acceptable to grant global access if desired. However, the situation is more complicated for the site with authenticated actions.

It is true that even with wildcard domains being prohibited, there is still the possibility that one of an authenticated site’s allowed domains could chain access to a potentially malicious third site. Unfortunately, short of banning cross-domain access entirely, there is no way to completely prevent this possibility. In most situations it would be impossible to map out a list of 3^rd and 4^th and n^th order chained domains at development time, and furthermore it would be pointless since the list could change at any time even after the app has been deployed.

In light of this research, we will be evaluating ways in which we can adapt the cross-domain requirement to continue to prevent unintended access from third-party domains. However, the requirement as it stands now remains useful and relevant. It raises the bar for attackers while imposing minimal design constraints and minimal time investments on the part of the development team.

Please let us know if you have any feedback on this requirement. Do you feel it’s too restrictive? Or maybe it’s not restrictive enough? Feel free to write us or leave a comment here.

Getting the Most for Your Security Investment

sdl — Tue, 06 Oct 2009 02:43:00 GMT

Hi everyone, this is Eleanor Saitta with iSEC Partners, with a brief post about return on investment and structured security.

A few weeks ago, Microsoft and iSEC Partners published a joint whitepaper titled, “Microsoft SDL: Return On Investment”, and I'd like to highlight a contradiction the paper discusses between what return on investment numbers show and common industry practice. In many cases, we see companies spending most of their security budget on gatekeeper-style security projects — right before the product is released, a security team gets called in to try to find vulnerabilities. This is more expensive and less effective than building security in from the start of a project and throughout the project’s development. Vulnerabilities are missed with the gatekeeper approach because in any large and complex system there's rarely time to look at every line of code and every function. That's not the worst of it, though — the cost of fixing the vulnerabilities found by the team can end up being huge because fixing security problems found late in the game may require a product be pushed back several stages in the development cycle and then retested to make sure no regressions are introduced and that the intended functionality didn't change.

This type of late-development churn is inefficient. In fact, the difference in cost between finding and fixing vulnerabilities early and fixing them once an application is about to deploy can be a factor of 30 or more (per a 2002 NIST study — see the whitepaper for more details) For example, if you're writing a web application and you perform an architectural security review, protecting against Cross-Site Scripting can be built-into the software as a functional requirement, and you can ensure that the application is designed so all output is correctly encoded. Putting in a point-fix at the right place in the framework and verifying that developers used the routine correctly is much easier and cheaper than trying to hunt down widely scattered cross-site scripting issues just as your ship deadline is approaching. Similar platform-level mitigations can solve a wide range of what are commonly considered low-level issues. Application platform vulnerabilities like Cross-Site Scripting or Cross-Site Request Forgery are what penetration testing is best at finding, but solving them up front with architectural review and secure design is still easier, cheaper, and more reliable than finding them in a gatekeeper-style penetration test and patching them.

In comparison, higher-level vulnerabilities in business rules, authentication, authorization or similar design issues can be both difficult to find and extremely time-consuming to fix if you only look for them once development has finished. Developers may have to change the core architecture of the system, leading to cascading code changes and regressions. On the other hand, a high-level security analysis (via threat modeling, security design review and related techniques) can be very effective at finding these types of issues. You can do this analysis even before development starts, preventing expensive architecture changes.

For both design and implementation vulnerabilities, looking at the return on investment shows that engaging with security early in a structured fashion is more effective than common gatekeeper-style security practices. When you’re making strategic decisions like this about how to approach security, good metrics that show what you’re getting for your investment make choices easier and your organization more efficient. Take a look at the whitepaper here for more information.

Known issue: Using MiniFuzz on Windows XP or Server2003

sdl — Fri, 25 Sep 2009 22:04:32 GMT

Michael Howard here with a quick update on MiniFuzz File Fuzzer.

We have received sporadic reports that a few MiniFuzz users are encountering an issue when attempting to run MiniFuzz on Windows Server 2003 or Windows XP platforms. This is a known issue that results from some missing registry keys on Windows XP and Server 2003 that are present in Vista and Server 2008 by default. We had documented this issue on the download site, but I wanted to also mention it here.

Below is a quick snapshot of the error and a simple command-line script that will automatically create the necessary registry settings and allow you to use MiniFuzz on these platforms. This should get you up and fuzzing immediately.

The error:

The manual fix:

Run the following command-line script to automatically create the necessary registry settings:

REG add "HKEY_CURRENT_USER\Software\Microsoft\Windows\Windows Error Reporting" /f
REG add "HKEY_CURRENT_USER\Software\Microsoft\Windows\Windows Error Reporting" /v DontShowUI /t REG_DWORD /d 1
REG add "HKEY_CURRENT_USER\Software\Microsoft\Windows\Windows Error Reporting" /v ExcludedApplications /t REG_MULTI_SZ

What we are doing about it:

We will be fixing this issue in MiniFuzz and putting up a fixed version of MiniFuzz in the future.

Thank you for downloading MiniFuzz. We apologize for this inconvenience, but hope this manual fix will help you begin fuzzing your applications.

New and Improved AntiXss 3.1, Now With Sanitization

sdl — Wed, 23 Sep 2009 23:39:00 GMT

Hi everyone, Bryan here.

As we’ve talked about on this blog many times in the past, the SDL requires the use of the Microsoft AntiXss library to defend against cross-site scripting attacks. However, we haven’t talked about the fact that until now, there have been two separate versions of AntiXss: one freely available to external users, and one restricted to use only inside Microsoft hosted data centers. Both versions include functionality to encode HTML output, so that injected script will be harmlessly rendered as text instead of executed by the target’s browser. However, the internal version also includes functionality to sanitize user input and remove potentially malicious script.

We have wanted to bring this internal technology to the external developer community for some time, so I’m excited to announce that the Information Security Tools team is including the HTML sanitization functionality in the new public version of AntiXss (version 3.1) and releasing the entire library under the Ms-PL open source license. Let’s take a quick look at how this functionality works and when you might want to use it.

When used correctly, output encoding is very effective at preventing XSS. However, a side effect of this is that it’s also very effective at preventing any type of user-specified HTML markup, whether malicious or benign. Yes, “<script>document.location='evil.com'</script>” should probably be blocked, but what about “I like strong coffee”? This is not malicious in any way and it seems overly restrictive to block it. (I’ll leave it to your own sense of good taste to decide whether the use of the <marquee> tag is malicious under any circumstances.)

Until now, the preferred way to selectively allow only certain HTML tags like and was to regex the input to ensure it contained only valid Unicode letter and number characters and those specified tags, something like this:

if (!Regex.IsMatch(input, @"^([\p{L}\p{N}'\s]||||){1,40}$")) throw new Exception();

This approach will prevent all unwanted tags, but it will also prevent all attributes on the allowed tags. Sometimes this is good – attackers can add malicious script to onmouseover attributes of and tags – but again, sometimes this is overkill and blocks the use of benign attributes like lang or title. It would be theoretically possible to extend the regular expression to allow these attributes, as well as other safe HTML tags and their attributes, but realistically that would be an incredibly difficult regex both to develop and maintain.

AntiXss 3.1 takes care of all of this logic for you, using the same whitelist approach: it filters the input using a list of known good tags and attributes and strips out all other text. Simply pass the untrusted input through the AntiXss.GetSafeHtml or GetSafeHtmlFragment method to sanitize it:

string output = AntiXss.GetSafeHtml(input);

I strongly encourage everyone to download the new AntiXss 3.1 and incorporate it into your applications starting today. It’s a very effective defense, especially when used in conjunction with the output encoding functionality that’s been a part of AntiXss from the beginning. And again, both output encoding and input sanitization are required by the SDL.

Finally, I’d like to thank both the Exchange team (whose HtmlToHtml library provides the sanitization logic) and the Information Security Tools team for bringing this functionality to the public, where it can do the most good for the most people.

Two New Security Tools for your SDL tool belt (Bonus: a “7-easy-steps” whitepaper)

sdl — Wed, 16 Sep 2009 16:01:00 GMT

Jeremy Dallman here to announce the release of two new security tools that will help you test and verify the security of your software – and meet some of the most critical requirements of the SDL. In addition, we are responding to customer requests and providing a basic 7-step guide for manually integrating key elements of the SDL Process Template into your existing Visual Studio Team System project.

As secure coding becomes an increasingly important piece of software development across the industry, we realize that security tools become a critical piece of your “security tool belt” and help ease adoption of security development best practices in your organization. In today’s economy, the tools that will get deployed are the inexpensive (or free) tools that effectively identify security issues, work seamlessly with your existing development environment and help teams implement the basics of the SDL.

Today we are making available BinScope Binary Analyzer and MiniFuzz File Fuzzer as no cost downloads.

We put together a couple of demo videos also. You can find them here: BinScope video & MiniFuzz video.

Let me briefly introduce you to each of these tools and explain why we think they are ideal tools to download and immediately include in your development lifecycle to verify the security of your code.

BinScope Binary Analyzer

What it does

The BinScope Binary Analyzer is an SDL-required security tool that has been used by Microsoft teams since the early days of the SDL. It analyzes your binaries for a wide variety of security protections with a very straightforward and easy-to-use interface. At Microsoft, developers and testers are required to use this tool in the Verification Phase of the SDL to ensure that they have built their code using the compiler/linker protections required by the Microsoft SDL.

The analyzer performs a diverse set of security checks. These checks include:

/GS flag is being set to detect stack-based buffer overflows
/SafeSEH flag is being set to enable and ensure safe exception handling
/NXCOMPAT flag is being set to enforce data execution prevention (NX)
/DYNAMICBASE flag is being set to enable Address Space Layout Randomization (ASLR)
.NET Strong-Named Assemblies are being used to ensure unique key pairs and strong integrity checks are in place
Known good ATL headers are being used
Up-to-date compiler and linker versions are being used (minimum Visual Studio 2005 SP2)
Reports on dangerous constructs that are prohibited/discouraged by the SDL (e.g. read/write shared sections, global function pointers).

How you use it

The BinScope Binary Analyzer can be downloaded as a standalone tool or as a tool that can be integrated into Visual Studio 2008. By offering these two options, this tool can easily and quickly help you build your code to meet the SDL compiler/linker protections.

(Figure above: stand-alone BinScope)

(Figure above: BinScope integrated in Visual Studio)

Extra Goodness

With an integrated installation of the BinScope Binary Analyzer for Visual Studio, validation is readily available in the development environment. In addition, BinScope integrates with Microsoft Team Foundation Server (TFS) to output results into work items. Finally, if your project is using the Microsoft SDL Process Template for VSTS, BinScope will seamlessly integrate with the template’s security work items and SDL Final Security Review reporting.

(Figure above: Easy output to TFS to create bugs and speed triage)

(Figure above: Seamless integration with the SDL Process Template reporting)

MiniFuzz File Fuzzer

What it does

The MiniFuzz File Fuzzer is a very simple fuzzer designed to ease adoption of fuzz testing by non-security people who are unfamiliar with file fuzzing tools or have never used them in their software development processes. A less capable and non-graphical version of this tool was originally published on the CD that came with the book The Security Development Lifecycle by Steve Lipner and Michael Howard. Since that tool was effective at finding quality bugs, we wanted to offer it more widely along with our other SDL tools, improve the user experience, and provide integration with Visual Studio and Team foundation Server.

Because fuzzing is effective at finding bugs, it is a required activity in the Verification Phase of the Microsoft Security Development Lifecycle (SDL). With the release of the MiniFuzz File Fuzzer, we have made a simple file fuzzer available to assist developer efforts to find and address more security bugs in code before it ships to customers. Simply provide the tool with a set of correctly formed files to serve as templates, and it will generate corrupted versions for testing. The effectiveness of fuzz testing can be increased by providing more variation in the template files.

How you use it

When you install the MiniFuzz File Fuzzer, it is provided as a stand-alone fuzzing tool that can be launched from your Start Menu. However, if you are using Visual Studio 2008, you can easily include the tool in Visual Studio as an Add-in Tool and launch it from there. In addition, the tool can also output to Team Foundation Server and integrate with the Microsoft SDL Process Template for Visual Studio Team System similar to the BinScope Binary Analyzer.

Whitepaper: Manually Integrating the SDL Process Template

The whitepaper can be downloaded here

After a successful release of the SDL Process Template for VSTS, we heard from some customers that they would like to include the key elements of the SDL into their existing team project. So, we figured out how to do that in 7 easy steps and wrote a whitepaper! This paper outlines the steps for manually extracting the key elements of the SDL Process Template and integrating them into an existing Visual Studio 2008 team project. By completing each of these manual steps, you can include the key elements of the SDL into your project without waiting until you start or build your next team project.

~~~~~~~~~~~~~~~~

That’s a lot of news for one day, but I hope you are as excited as we are to be releasing these tools and making it possible for more development teams to write secure code and adopt the SDL. We welcome your comments and questions as you download and begin using these tools!

[edited: 9/16/09 11AM - added links to videos]

Application Security Street Fighting

sdl — Thu, 03 Sep 2009 23:29:00 GMT

Hi, this is Johannes Ullrich from SANS.

As CTO of the SANS Internet Storm Center www.isc.sans.org , I lead the development of complex and exposed applications. Recently, SANS www.sans.org became a member of the SDL Pro Network. I am happy that I will be able to teach the SDL curriculum in San Diego September 15^th http://www.sans.org/ns2009/.

As a developer, you are faced with an almost impossible task. Even small projects process hundreds of pieces of input data, provide access control to multiple users and interact with multiple systems like databases and browsers. If you make one mistake, one single SQL injection flaw, one function with insufficient access control, you lose. On the other hand, an attacker only has to find one single flaw in order to breach the application.

How do you “win” given these unfavorable odds? One mistake made by developers is to worry too much about individual lines of code forgetting about the big picture. As part of teaching developers about secure coding and defending web applications, I have started to adopt a philosophy I describe as “application security street fighting”. This philosophy focuses on easy and repeatable coding techniques. These techniques do not require developers to become security experts. Instead the approach focuses on using the right tools and principles to guide developers to create secure applications that can be efficiently implemented and maintained.

1 – Simple repeatable coding techniques

One aspect of street fighting, as compared to martial arts practiced in dojos and exhibited in competition is the fact that complex techniques don’t work. A quick kick to the groin usually beats the complicated judo throw. For a developer, this means that standard problems have to be solved in simple, repeatable ways. For example, the ever-present issue of SQL injection is easily addressed. By writing a simple library to enforce the use of prepared statements, the need to implement and secure SQL statements one at a time will diminish.

Another example is user input validation. We typically teach developers to write two lines of code. One line is to retrieve the data from the user, and another line to validate that the data is in the expected format. In my opinion, this is one line of code too much. Instead, write a library once that will retrieve the data and validate it. Going forward, the developer will now only call one function, which will retrieve and validate the data. To illustrate, a little bit of pseudo code:

First the traditional way:

Userdata=GetInput(‘email’);

If ( ! is_email(Userdata) {

Error

}

Next the better version:

Userdata=GetEmail(‘email’);

2 – Threat Focused Coding

Once we get past simple issues like SQL injection and input validation, our developer is able to focus on more challenging security problems such as: How am I going to accurately describe the business logic?; or Which techniques could an attacker use to bypass access control restrictions? The developer’s focus will shift from individual lines of code to the larger threat. Threat modeling, an important part of the SDL, will now become much more meaningful to the developer. To apply a street fighting metaphor: Don’t look at your gun, look at your target. You need to know what is happening on a macro level and not get lost focusing on details.

3 – Training

Even simple techniques will not work if they haven’t been taught and practiced properly. There is a point for “dojo” style training in which you are presented with a set scenario and a safe environment in which to practice. This training needs to be applicable and based on real life situations in order to be effective. One thing I liked about the SDL curriculum developed by Microsoft is that it comes from a company that is able to apply these techniques in its own products. Software security training should not just come from security people, but be strongly influenced by developers. Aside from classroom training, there are plenty of other opportunities to learn and practice in your day-to-day job. It is also important to distinguish between training and practice. Training focuses on learning new skills, usually from an outsider. Practice on the other hand is all about applying what you learned and repeating it. Practice can benefit from outside feedback, but it can also be done on your own. Classroom training should illustrate how you are able to practice what you learned once you get back home. At SANS, one of our long-standing promises has been that what you learn in class, you will be able to apply the day you come home. If it would be any other way, we would only teach skills which you will never use and eventually forget.

4 – Conclusion

The SDL starts with training. Training your developers to reuse code and, to use simple and repeatable techniques to code securely will pay off later during implementation. Code reviews will be easier and faster if developers adhere to these guidelines. Even your response plan can harness the same principles by automating the detection and response to common attacks.

As I’ve discussed here, Application Security requires a combination of knowledge, basic skills and practice so that defending applications through secure coding is done instinctively. The MS SDL process is a great toolkit and leverages the hard lessons learned over the years in security. If you’d like to learn the basics in a one day class, I’ll be teaching the MS SDL in San Diego on September 15^th. Check it out and register at http://www.sans.org/ns2009/.

"The Threats to Our Products"

sdl — Fri, 28 Aug 2009 00:48:00 GMT

Adam here.

I’ve learned to love STRIDE as a framework for thinking about threats, but it makes a lousy classification system. That is, I can look at a system to find information disclosure threats, but once I have an attack that leaks, say, the location of a DLL in memory to a remote attacker, is that Information Disclosure or Elevation of Privilege? It’s likely to make the latter easy, and down the classification rat-hole we go. I’d like to suggest that calling it ‘the STRIDE framework is the most clear wording we can use.’

I found the 1999 internal Microsoft article written by (then) Microsoft employees Loren Kohnfelder and Praerit Garg, and was pleased to discover that they intended STRIDE “to help you identify potential vulnerabilities in your product during a security analysis.” They also make repeated reference to a “proactive security analysis process,” and shows some of the thinking that led to the SDL. I thought it was neat look into history, and so without further ado, it's attached. (59KB .docx)

A Gritty Policy

sdl — Thu, 13 Aug 2009 23:37:00 GMT

Hi, Bryan here.

For any of you that might not have seen the movie Sneakers, I’ll try to not spoil the plot completely for you, but the main storyline revolves around a “little black box” that a scientist has developed that can automatically defeat asymmetric encryption. It’s a fun movie, but what if this happened in real life? After all, crypto algorithms are broken all the time – either through little black box cleverness or simply through improved access to brute force processing power. If RSA, AES, SHA-2 or any of the other current SDL crypto standard algorithms were to be broken tomorrow, what kind of changes would you have to make to your applications? If you’ve hardcoded that algorithm into your apps, you’ll probably have to make some emergency code changes to use a new algorithm, issue patches to all of your users, and then hope that the new algorithm you chose doesn’t also get compromised. However, there is a better way to handle this scenario.

The SDL requires all applications to be able to upgrade the algorithms they use over time. This is usually referred to as the SDL crypto agility requirement. Both the .NET framework and the Cryptography API: Next Generation (CNG) include some useful features that can help you make your code more cryptographically agile; in fact, if you write your application the right way, you’ll be able to change algorithms with simple configuration file edits – no code changes required.

For .NET code, the first step in crypto agility is to avoid hardcoding any particular algorithm or algorithm implementation into your code, and instead refer only to the abstract class of algorithm you need. Instead of instantiating a SHA256CryptoServiceProvider object (for example), you would declare an abstract HashAlgorithm. Instead of instantiating an AesManaged object, you would declare an abstract SymmetricAlgorithm. You can’t instantiate an abstract class, but System.Security.Cryptography abstract algorithm classes expose static Create methods. So instead of this code:


SHA512Cng sha = new SHA512Cng(); // not agile!

You would use this code:


HashAlgorithm hash = HashAlgorithm.Create(“SHA512”); // more agile

This new code doesn’t look any better than the old code – it looks like we’ve still hardcoded SHA512 into the application. But we actually haven’t; we’ve only hardcoded the string “SHA512” into the application, and we can edit the machine.config file to redefine which class actually gets instantiated when an application tries to create a “SHA512” object.

An even better alternative is to define application-specific configuration strings and write these both into the code and into the machine.config files of systems where the app is deployed. This is safer than redefining a common algorithm string like “SHA512”, because you can upgrade the algorithm used by an individual application without affecting any other apps:


HashAlgorithm hash = HashAlgorithm.Create(“MyApplication_PreferredHash”); // most agile

If you’re writing native C++ code, you can accomplish the same goal with CNG. Again, the first step is to avoid hardcoding algorithm names into your code:


BCRYPT_ALG_HANDLE hAlg = NULL;
NTSTATUS ret = BCryptOpenAlgorithmProvider(&hAlg, L"SHA256", NULL, 0); // not agile!

Instead, load the desired algorithm provider string from a configuration file, or the registry, or some other location. Just be sure to apply an appropriate ACL to the resource where you’re storing your setting! You don’t want unauthorized users reducing the security strength of the application by reconfiguring it to use a weaker algorithm.


LPCWSTR algName = NULL;
// load desired algName from the registry
…
NTSTATUS ret = BCryptOpenAlgorithmProvider(&hAlg, algName, NULL, 0); // more agile

In most cases, some additional work will be required in order to make crypto agility code work correctly. For example, if you’re storing password hashes for an authentication system, you can’t change just the comparing algorithm and expect the system to work. If the stored hashes are MD5 and you start comparing them to computed SHA-2 hashes, no one will be able to log in. In this case, you’ll need to store metadata about the algorithm used along with the stored password hash. When authenticating the user, instantiate the exact algorithm they originally used to create the password hash. Once they’ve authenticated, check whether the algorithm used to create their hash is out of date. If so, prompt them to create a new password, then create and store the new password hash using the new preferred algorithm.

Of course, this example is just the tip of the iceberg. If you’re interested in reading more about crypto agility, including more code and configuration samples, be sure to check out the Security Briefs column of the current MSDN Magazine, the Cryptographic Enhancements chapter of Writing Secure Code for Windows Vista, or Shawn Farkas’ (of the CLR Security team) blog. As always, questions and comments are welcome.

Setting SDL memory-related Requirements before your Application Starts

sdl — Thu, 06 Aug 2009 21:15:00 GMT

Hello, Michael here.

A word of warning, this is purely an “FYI” post that has very little to do with SDL policy!

I get this question, “How do I call various SDL-mandated APIs before my code starts?” about once a month, so I decided to write about it so I don’t have keep dragging up the same email over and over! The question roughly translates into “Can I call some setup code before main() starts?”

The answer is ‘yes’! But why would you want to do it? One reason is perhaps you want to call the SetProcessDEPPolicy API because you don’t have access to a compiler with the /NXCOMPAT option, or perhaps you want to call HeapSetInformation very early in your code because main() handles untrusted data. Or perhaps you want to create a library for your developers to link with and not require them to add new API calls to their code. But probably the most important reason is if you want to update many EXEs but don’t want to change the code, all you need to do is link with the OBJ file. That’s it!

Visual C++ allows you to define your own code sections that are called by the C startup runtime code prior to calling main(). The following code snippet could be compiled to a .OBJ and then linked with your C or C++ project and will call the SetProcessDEPPolicy API to set the NX bit on your process. You can add most any API in here.

static int __cdecl SDLSetup(void) {

HeapSetInformation(NULL, HeapEnableTerminationOnCorruption, NULL, 0);

HMODULE hmodKernel32 = GetModuleHandleW(L"KERNEL32.DLL");

BOOL (WINAPI *pfnSetProcessDEPPolicy)(DWORD);

*(FARPROC *) &pfnSetProcessDEPPolicy

= GetProcAddress(hmodKernel32, "SetProcessDEPPolicy");

if (pfnSetProcessDEPPolicy != 0)

(*pfnSetProcessDEPPolicy)

(PROCESS_DEP_ENABLE | PROCESS_DEP_DISABLE_ATL_THUNK_EMULATION);

return(0);

}

static __declspec(allocate(".CRT$XIAA")) int (__cdecl *pfnSDLSetup)(void)
= &SDLSetup;

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.

URL Rewriting Session at Black Hat

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

Hi everyone, Bryan here. I wanted to make a quick (and shameless) plug for my session at Black Hat this week. I’ll be talking about the use of URL rewriting as a defense against XSS, XSRF, open-redirect phishing and browser history theft that I’ve discussed in the past both on this blog and in MSDN magazine.

In conjunction with my talk, I’d also like to announce availability of a proof-of-concept URL rewriting tool that implements the concepts illustrated in the talk. The rewriter is implemented as an HttpModule for ASP.NET applications – activating this module for use in your own code will typically require one new line of code and one change to your web.config file.

You can download the tool here, but again I’d like to stress that this is a proof-of-concept and should not be used for any production code. Please do feel free to test it out and even decompile it if you like – just let us know where it works, where it doesn’t, and how it can be improved.