Hi, Michael Howard here (again).

Before I get started on this post, I want to set some expectations. My plan is to blog occasionally about our root cause analyses, but I will not blog about every vulnerability we fix simply because I don't have the time; while we analyze each and every vulnerability we address in a bulletin I want to highlight only those that can help customers better understand particular elements of how this works with SDL . With that in mind, I will blog about vulnerabilities that interest me, and most will be critical in one or more of our products. Finally, I outline specifically how the vulnerability in question relates to potential SDL change or improvement.

As you are probably aware, Microsoft recently issued a security bulletin that fixed a security vulnerability in the DNS server code in Windows Server components. I want to spend a couple of minutes to explain the vulnerability and how various versions of Windows server were affected, and most importantly, what we learned from the vulnerability.

Which products are affected?

It's important to note, this vulnerability is in the DNS server code and is only in the Windows server platforms; Windows XP and Windows Vista users are not affected at all because the client operating systems do not include DNS server code, only DNS client code.

The DNS server is not enabled by default, except when Small Business Server is installed, or the computer is configured as an Active Directory domain controller.

Windows 2000 and Windows Server 2003 systems running DNS are affected, as is "Longhorn" Server beta 2, but we fixed the vulnerability in time for beta 3. In fact, to protect customers, we chose to run the real risk of slipping beta 3 to include this change.

The Nature of the Vulnerability

The vulnerability is in code listening on ephemeral RPC ports used for DNS server management, the vulnerability is not in the mainline port 53 DNS processing code. Since Windows XP SP2, we made RPC communication authenticated by default; this was a direct outcome of lessons learned from the Blaster worm. But what's interesting is that this RPC end-point is anonymously accessible.

In and of itself, anonymous access is not a security vulnerability, it's an attack surface issue because an anonymously accessible entry point has a larger attack surface than an authenticated entry point.

The Code

The vulnerability is a stack-based buffer overrun in a structure; the structure that's overrun is:

Hi, Michael here.

A few weeks ago, my boss, Steve Lipner placed a copy of eWeek on my desk opened to an article entitled, “Java Security Traps Getting Worse.” In summary, the article, which is also available online (http://www.eweek.com/article2/0,1895,2128071,00.asp) lamented the state of security in applications written using Java. I’ll let you read the article and draw your own conclusions, but I have my own thoughts on the problem, and I want to explain my position by way of example.

In 2003, I presented a paper on the SDL at the Workshop on Software Security (http://dimacs.rutgers.edu/Workshops/Software/abstracts.html) and the topic of conversation turned quickly to how bad the C and C++ programming languages are from a security perspective. Someone from the audience shouted out that “We should just ban C and C++ and replace it with Java.” I replied that we could ban <insert programming language of choice> and replace it with <another programming language of choice> and we’d still have lots of security bugs. I said this because programming languages by themselves don’t make secure code, but I believe that a number of people believe they will. I think a good many people believe that so long as the language is not C or C++, then the code is inherently secure.

This belief in a programming security silver bullet is very dangerous, and I believe we address this nicely in the SDL. In fact, a lack of a silver bullet is a core principle of the SDL. We teach people, actually, no we don’t teach people: we ram it down engineer’s throats: the number one skill a person designing, building or testing software should learn is that input should never be trusted. Regardless of OS or programming language. Ever.

Don’t get me wrong, I’m not bagging the data in the article; I’ve seen people believe that .NET code is a security panacea, and it’s not. In all of our SDL education we stress the point that .NET code is not a security cure-all, and we make sure that developers understand that if you choose to ignore the golden rule about never trusting input no language or tool will save you. Using safe string functions can help mitigate risks of buffer overruns in C/C++, but won’t help with integer arithmetic, XSS, SQL injection, canonicalization or crypto issues.

The key point is that languages are just tools; anyone using a tool needs to understand the strengths and limitations of any given tool in order to make informed use of the tool.

One final thought; in my opinion, well-educated software developers using C/C++ who follow secure programming practices and use appropriate tools will deliver more secure software than developers using Java or C# who do not follow sound security discipline.

Hi – Dave here.

If you have read Michael Howard’s blog for a while, you may recall that our team held a two-and-a-half day SDL training session back in November for fifty senior engineers from a number of the hardware OEMs and some of their component suppliers.  At that time, we heard strong feedback from the group that they wanted us to work with other sectors of the IT community, (particularly with ISVs) to get more people attuned to the importance of security development practices. Since that time we have been doing mostly individual engagements – informally briefing and working with customers, partners and others usually on a one-to-one basis.
 
Yesterday, we held a somewhat shorter version of the November session for an interesting mix of security-focused groups as part of the Microsoft Security Response and Safety Summit (MSRSS).  MSRSS is an event focused on sharing information with a number of different security groups that comprise the Microsoft Security Response Alliance and the Secure IT Alliance.  Our track was one of two running concurrently – we had forty or so in attendance from government, ISPs, AV vendors, CERTs, security ISVs and the like.

Scott Charney opened the event with a discussion about the evolving threat environment – he emphasized the need for cooperation and information sharing from all the players in the IT security space. After Scott’s call to action, we moved into the training portion of the day.  Most of the SDL blog gang presented – Eric Bidstrup provided an overview of the SDL; Adam Shostack discussed the threat modeling process and how it is evolving; Michael Howard did a variant of his “Writing Secure Code” talk; James Whittaker talked about security testing and the final session focused on privacy, with Tina Knutson and Sue Glueck.  In November, I gave a talk on the intersection of security policy and development practice – given the time constraint, this time I gracefully accepted the role of emcee and checked hats and coats for the attendees.  : ^ )

At first I was a little concerned about the potential for “impedance mismatch” – after all, we were talking about the various facets of security development methodology and this was an event traditionally focused on how to collaborate effectively in a time of security crisis.  It occurred to me about half way through the opening talk that it was okay if this wasn’t a developer to developer talk – everyone in the room had “a dog in the security fight” and as a result, it’s incumbent upon us to have as many conversations with folks in the community (regardless of discipline) as we can.

Exposure to these partner groups provided us with interesting perspectives – the attendees asked good questions (a few of them pointy) and many of us were corralled during the breaks for robust discussions on a variety of subjects.
 
Some of you may be thinking "So what? Microsoft had another security event – whoopee!!”  Fair enough.  However, in our defense, I’d like to make two points.  First, I think it’s mildly amusing that the notion of Microsoft hosting a security collaboration event has become so commonplace – it wasn’t so long ago that Microsoft and security couldn’t be uttered in the same sentence without fits of laughter – it’s interesting how times change.  Second, (and of far greater importance) we strongly believe that it’s in the best interest of protecting our mutual customers to work with these groups and share our knowledge. Conversely, it’s an opportunity for us to learn about emerging issues and concerns that we typically aren’t exposed to on a day-to-day basis.

Bottom Line: It was a great opportunity and a practice that we will no doubt carry forward.

Rob Roberts here.

Software test engineers have a lot of things to consider when testing their products: performance, security, accessibility, reliability, usability, and a whole bunch of other “-ilities.” And now to address our increasingly interconnected world, they have yet another important area to evaluate - privacy.

It’s hard to imagine a testing topic more arcane than security but privacy may be just that. Just like software security, privacy isn’t taught in universities, there are few engineering-oriented books on the subject, and just what it means to do privacy testing is still being worked out. You can’t have privacy without security, but there are many other things to consider around privacy besides keeping data secure.  To help narrow what privacy behaviors testers should consider, we provide an approach for test teams as well as some basic tools they can use to understand the specific privacy scenarios relevant to their application. 

The definitive source for all things privacy in the SDL is our internal privacy guidelines for developing products and services (the public version is posted here).   This document considers a wide range of privacy scenarios from storing customer information in the enterprise to privacy considerations around developing and publishing Web sites.  It includes quite a bit of detail – something our privacy Subject Matter Experts (SMEs) depend on to do thoughtful and thorough privacy reviews.  While some privacy testers may want to understand every nuance in this material, many would prefer to be given something that was more focused so they can concentrate on what they do best: breaking software.  To streamline the development of privacy “test” scenarios, we distilled the guidance and identified these three key steps for testers:

Step 1 Understand what data is collected and how it is used.

Test Engineers examine documentation (threat models, specs, design documents and so forth), meet with feature experts, and review source code to determine what data is being collected, stored and/or transferred by their application. This “data” includes all input, local storage (temporary or persistent) or remote storage that the application can access. Once they know what data is in play, they must classify it by type (anonymous, PII, sensitive PII), context (local storage vs. transfer off the system), and visibility (e.g., hidden metadata).  If necessary the tester can then validate these classifications with a privacy SME to determine what user information is potentially at risk, and how that risk is mitigated by the application.

When testers know what the data is and exactly how it flows through the system being tested, they identify the privacy impacting scenarios of their application.  Based on our privacy guidelines we created a “Privacy Bug Bar” to describe potential privacy bugs and their severity. 

A tool we are prototyping for select internal groups is an interactive form for test engineers to identify privacy impacting behaviors and receive a summary of the applicable privacy scenarios (from the privacy guidelines) along with pre-defined bug bar information for those scenarios.  This tool is expected to save test engineers time in assessing privacy issues by giving them only the relevant privacy scenarios that affect their project.

Step 2 Review the application’s privacy statement.

During development privacy SMEs work with teams to create privacy statements for projects with privacy impacting behaviors.  An effective privacy statement informs users how the product, service, or web site behavior impacts their privacy, and what controls are available to change those behaviors.  Part of the tester’s responsibility is to ensure the published privacy statement accurately represents what their application does.

Step 3 Verify data use.

Armed with the knowledge of relevant privacy behaviors from steps 1 and 2, testers can now enhance their test cases by including privacy-aware scenarios throughout their functional testing.  If their testing discovers a violation of the guidelines then the predefined bug bar will help them rate its severity.

One of our biggest concerns in the privacy space is off-system communication, or what we call “phoning home.” An example of phoning home is software that goes online to check for newer versions or security updates.  Applications often rely on the ability to communicate across networks, but as data moves further away from the local system, risk of data exposure increases. When applications phone home, care needs to be taken to assure that this communication happens only with the customer’s permission, that they know what data is being sent, that the data is sent securely, and how it will be used upon reaching its destination.  Currently many test teams rely on very basic network monitoring to validate when their application is phoning home.  This is a manual and time consuming process that we are working to automate.

With this approach and our ongoing commitment to automation we are working to embed privacy into the testing process so that testers understand the relevant privacy scenarios for the software they are testing and enhance their ability discover problems before the software ships.

Privacy is important to users, and is a major component to building trustworthy software.  Testers play a key role in meeting the privacy demands that the SDL places on Microsoft products and services.