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:

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.

First up is a code review quiz, “Test Your Security IQ”. Put your C/C++/C# security skills to the challenge by reviewing ten tricky code snippets that Michael and I devised. As an added incentive, I’ll post public congratulations here in the SDL blog to the first person who reverses the insecure hash found somewhere in the exam (not to give too much of a hint).

Next up, we have “Agile SDL: Streamline Security Practices for Agile Development”. I’ve been talking about web application security issues in the SDL blog (and in the September issue of MSDN magazine, if you missed it). However, while it’s essential to make sure that web-specific issues are covered in the SDL, it’s equally important to make sure that web development teams – and other Agile development teams – can use the SDL effectively, and the classic, phased SDL approach is not always a good fit for these teams. This MSDN article is the first public look at the new SDL/Agile methodology that we’ve been working on for the last year. This process is currently in beta with some internal Microsoft product teams and online services. We’d love to get some external feedback on it before we release it to the entire company, so please send us your thoughts.

Finally, be sure to check out Michael’s Security Briefs column “Threat Models Improve Your Security Process”. Regular readers of this blog know how important threat modeling is to secure development. This article describes methods of using threat modeling not just to identify security vulnerabilities outright, but how to use it to make other SDL activities such as fuzzing and reducing attack surface more effective.

Three articles are more than enough for one team for one month! But be on the lookout for more articles from the usual SDL suspects in the near future. As always, keep watching this space for details.

The analysts paired up today:
Antonio Piraino (Tier1 Research)
William Fellows (The 451 Group)

My usual disclaimers on live-blogging: doesn’t include everything covered (just what was most interesting to me) and had to paraphrase some answers because I simply cannot type that fast.

Quick definition of Cloud Computing
WF: The cloud is a continuum of grid, virtualization and utility done right. It is about provisioning services instead of servers; flexible computing instead of fixed assets. Done right, the cloud abstracts users from the complexity of grid. Cloud computing is IT as a service. Cloud computing is the Third Way – not entirely in-house or outsourced, but an optimized hybridized version of both. In light of the Goldman Sachs report out resetting IT spending forecast from up 6% to down 1%, don’t underestimate the ability for enterprises to move from capex to opex by buying cloud computing instead of building it themselves.

The 451 Group conducted a survey on cloud computing in March, and then revisited it a month ago. Some interesting results:

• 84% have no plans to develop an internal cloud. 5% had no answer to this question. And for the 10% who did answer – the uses for a private/internal cloud were the same as those for a public cloud.
• Top 6 vendors they look to help them develop an internal cloud: Microsoft, IBM, Cisco, HP, Oracle, VMware

Is it all “upside” when it comes to cloud computing?

WF: Watch out for the Trojan horse, the red flag. What about the software needed to manage all this stuff? Any management software needs to take a holistic approach to solve the problem.

AP: Increased management requirements and capability – this is actually a great story for managed hosters who can hold your hand while getting you up into the cloud. Hosters alleviate the pain points, and this is why we’re going to see continued growth and focus in the managed hosting sector.

WF: I would argue that they’re too expensive. Look at Amazon – 10 cents a hit adds up.

AP: It’s almost impossible to do an apples-to-apples comparison between cloud providers. One reason is that they charge differently. I’d say that when you’re talking about the big cloud providers, you are right – that they are expensive over the long-term, but for use in the short-term, they can be optimal.

WF: The cloud is setting big expectations. Can IT deliver? It’s nice to talk about “shared resources for the greater good” but in any organization, you will still run into issues of power and control! Plus it’s still early days for resolution of regulatory issues and compliance around the cloud.

Final Thoughts

AP: Think of the opportunities of using cloud computing resources in the areas of testing and pre-production – short-term use/environment (quick up/quick down), inexpensive, opex not capex. We’re already seeing the cloud fostering much innovation.

WF: “It’s okay to fall in love with the term.” It is real but keep the expectations lower and realistic.

AP: I agree with you. The reality is that the cloud is driving a very fundamental underlying platform change. This is not just a term or something that will fall out of fashion. There’s a real need to build trust in the cloud and leveraging shared resources in this way – so use the cloud computing term cautiously; don’t abuse it and make the cloud seem like IT’s new toy.

1. “A Gartnergate?” What happened after Mr Pescatore uttered his now famous 12 words: “The best security program is at the business with the happiest customers.” This (complete with Gunnar’s famous “firewalls+SSL” chart), this – will add more as this snowballs.
2. Do you have an “ignorable” security policy? If yours is BOTH “ignorable” and “unfair”, then fuggedaboutit. Cisco survey kinda proves it. A few fun comments are here (“If people can't get their jobs done without having to find a way to circumvent policy then the policy is wrong.”)
3. Risk and clouds – here, here, here and here in poetic form (!). Fun reading, but you know what? For many, many organization, what they have today is LESS secure than any future cloud computing advance…
4. Richard Bejtlich drop-kicks SIEM too, then kicks it in the balls. Then kicks the dead horse (1,2,3)
5. Excellent reminder about why people don’t care about security with a fabled quote from MJR (yes, it is my fave too!) Overall, Rich “reassures” with: “Don’t worry. When things get bad enough, we’ll get the call. If you’ve kept your documentation and communications up, you won’t get shafted with the proverbial short end.”
6. A few essays on risk, from ANSI, from Schneier and from BlogInfoSec (part 1 and part 2, especially read part 2)
7. So, what do CTOs really do every day? Interesting summary here and here.
8. Fun exploration of security x privacy x compliance.
9. Burton Group opines on which security technologies will fare better/worse during "The crisis”
10. A really fun interview with our CEO Philippe Courtot here.
11. More on IT vs IT security, this time from Richard.
12. Do you want people like that doing “security”? A normal call center employee recognizes fraud, but their so-called “outsource security dept” authorizes the scam. Niiice.
13. Finally, “Robots Hunt 'Non-Cooperative Humans' in Army Plan” No comment :-)

Enjoy!

Information Week’s new blog, Plug Into the Cloud, is already in the thick of the controversy on the emerging cloud computing trend. A recent post lists a bunch of highly opinionated comments on the topic by site visitors, running the gamut from “Cloud computing is kind of like the Emperor’s New Clothes” to “cloud software can actually be more expensive than the software I load onto my hard drive.”

Jeff Doyle writes an interesting post about resistance to IPv6 adoption (what, you think we forgot?). Instead of the usual focus on IPv6 as an application issue, he points out that it’s actually an infrastructure thing. Would you wait to upgrade routers, switches, software, or servers until you can find a way to make the newer systems profitable? Would you wait to increase bandwidth only after you have customers waiting to use it? If you’ve answered these questions “no”, then why are you waiting to upgrade to IPv6?

We posted about whether or not there were recession proof products in IT yesterday. Network World Management Maven Denise Dubie also writes about readers weighing in on IT and the economy – from having to do even more with less to seeing the economic downtown as an opportunity to highlight IT’s true value to the business.

And finally, on the lighter side: What would we do without crazy billionaires and their crazy purchases? According to a New York Times article, a company controlled by Google’s top execs just added a fighter jet to their roster. “Presumably no attacks on Microsoft are planned at this time.” (image from Wikipedia)

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 teh 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 allusions 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 scenarios.

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.