Hi everyone, Bryan Sullivan here.
I’m having something of a dilemma today. An important part of my job is keeping current with security issues so that we can provide appropriate guidance for dealing with those risks in the SDL. A great way to keep current with security issues is to hang out at hacker cons. Now on one hand, I really love hacker cons. I always find sessions that are relevant, I always meet interesting new people and catch up with old friends, the liquor flows freely at the after-parties…there are lots of great reasons. And it’s fun to speak at these shows too. But I have to honestly ask myself, how much good am I doing? If I stand in front of a group of netadmins and pentesters and describe a new method of hacking Ajax apps, what have I really accomplished? I suppose that a few of those people might use my ideas to find vulnerabilities in the field, which is good. But security shouldn’t start with the pentester – after all, you can’t test security into a product. Security should start with the developer, and then continue on with the tester, the pentester, the netadmin, and everyone else in the product lifecycle.
Instead of teaching pentesters how to find vulnerabilities, I’d rather be teaching developers how to write their code correctly in the first place so that the pentesters don’t have any vulnerabilities to find. But, as a general rule, developers don’t really attend hacker cons. They attend developer cons. There are of course exceptions to this rule, but ask yourself honestly: How many people do you suppose really go to DEFCON to learn how to write secure code versus those who go to learn how to break things? Now, I love developer cons too. I always find sessions that are relevant, I always meet interesting new people and catch up with old friends, and while the liquor may not flow quite as freely I still always manage to have a great time. But here’s the dilemma: developers don’t go to developer cons to hear about security. They go to hear about sexy new OS or language or compiler features. There’s nothing sexy about developer security. Nobody wakes up on Monday morning and says, “Wow! I get to go work on developer security issues today! Awesome!” OK, I have to admit that I actually do this – really – but I’m probably an atypical example. For most people, following the SDL is a lot like flossing their teeth. They know they’ll regret it later if they skip it, but that doesn’t make it any more fun right now.
So what can we do to make security a little more fun? What’s the adult equivalent of a Hello Kitty or Power Rangers toothbrush? For better or worse, I haven’t been able to think of one. But maybe we can take a different approach to the problem. What if, instead of trying to make the SDL fun, we tried to make it as painless and unobtrusive as possible? To put it another way: What if, instead of having to floss your teeth yourself, little gnomes came in and flossed your teeth for you while you slept? (OK, that’s a little creepy, but you get the point.) Think about the /GS compiler option in Visual C++, or the ValidateRequest page directive in ASP.NET. These security features provide excellent defenses against stack overruns and cross-site scripting attacks (respectively), and the best part is that developers get them essentially for free. If we can automate enough SDL requirements this way, developers could spend more time implementing new features and less time worrying about security. And that would be truly sexy.
Hello all - Dave here
For a change of pace, a few of the SDL blog crew decided to take a poke at a "Security Predictions for 2008" posting. In selecting a prediction, the only guiding rule was that the prediction had to cover something that could be influenced by application (or lack thereof) of the Security Development Lifecycle - either within Microsoft or in the industry. A few of the bolder souls among us decided to provide a single prediction below, followed by a short paragraph or two elaborating on why they think this will occur and the relationship to SDL.
In addition, we'll take this opportunity to introduce two new folks who recently joined our team: Bryan Sullivan and Jeremy Dallman. Welcome! A brief introduction paragraph from each of them in included below, followed by the predictions. Hope you enjoy...
Bryan Sullivan: Hi everyone - my name is Bryan Sullivan and I'm new to the SDL team. I've spent the last five years as a developer and security researcher at SPI Dynamics, and I'm looking to bring the same web app security focus that I had at SPI here with me to Microsoft. I'm particularly interested in emerging security issues with Rich Internet Application frameworks like Ajax, Flash and Silverlight, so expect to see me blogging and speaking on these topics throughout the year.
Jeremy Dallman: Hi, I’m Jeremy Dallman. I’ve been at Microsoft since 2002 - starting in Windows Security on early versions of Vista. Shortly after Blaster, I was reassigned to the XP SP2 project and spent the next year as the project manager for the Windows Core Security team living the whirlwind of that release. I have spent the past three years on the Internet Explorer security team in a variety of roles managing security response as well as IE7/8 security requirements and planning. I moved over to the SDL team this past October to extend our internal SDL processes to the world and create outreach programs that will help development shops implement secure development lifecycle practices.
Now, on to the predictions!___________________________________________________________________________________________________
Eric Bidstrup:
My prediction for 2008: "Vulnerabilities in commercial and non-commercial software will continue to be reported to CVE (as tracked in the US National Vulnerability Database) at a record pace. However, the number of newly reported vulnerabilities in Microsoft products will decrease when expressed as percentage of overall CVE vulnerabilities in 2008
A query of the NVD with "Vendor=Microsoft", "Start Date= January 2007", and "End Date=December 2007" returns 254 matches. A query of NVD without selecting any vendor, and choosing "Start Date= January 2007", and "End Date=December 2007" returns 6532 matches. If my math is correct, that states that Microsoft was responsible for 3.8885 percent of the vulnerabilities in the NVD in 2007. My prediction is those same queries and same math for 2008 will be less than 3.8885 percent. Before anyone starts commenting about how good or bad the NVD is, let me just state that it's an independent baseline with metrics that (assuming no major changes in policy or tracking practices in 2008) will have the same attributes at this time next year.
The motivation for my prediction is that via application of the SDL, Microsoft will continue to reduce vulnerability rates in our products. Sadly, there are not many other software vendors that have stepped up and made the same level of commitment to delivering trustworthy software. Hence, Microsoft will be responsible for a smaller overall percentage of vulnerabilities in 2008. Ideally, I wish the overall NVD vulnerability count would decrease as an absolute number, as that would be an indicator that the industry as a whole was improving. Unfortunately, I don't think this will be the case.
Adam Shostack:
My prediction for 2008: I believe that 75% or more of all privacy breaches will not involve an exploit, but will involve some other sort of operational security failure, such as lost or stolen hardware or inadvertent sharing of data.
To be precise, 75% of the breaches listed in the attrition.org DLDOS will be categorized as something other than "hack."
Bryan Sullivan:
My prediction for 2008: I predict that in 2008 we will see at least a 50% increase in the number of Cross-Site Request Forgery (XSRF) vulnerabilities as reported in the US National Vulnerability Database. The root of request forgery vulnerabilities - relying solely on cookies for authenticating users - is more of a design flaw and not a simple implementation issue. This makes them tougher to identify and to remove. They can't be mitigated solely through input validation techniques the way that Cross-Site Scripting and SQL injection can.
As the new web application security guy on the SDL team, it's my job to improve mitigations for issues like request forgery in the SDL, so that it is just as useful and applicable to online services as it is for desktop and client/server programs. Keep watching this space for web app-specific updates to the SDL and for a more in-depth look at XSRF in the near future.
Hi, Michael here. Happy New Year!
Recently, Symantec issued a security advisory warning users of critical remote code-execution security vulnerabilities in various Symantec email security products. The bugs caught my eye for a number of reasons:
Symantec's advisory and some of the ensuing analysis were a goldmine of information for me. The vulnerabilities are not in Symantec code, yet Symantec customers are still open to attack. The issues lie in a small number of file parsers used in many applications created by a third party vendor. As you probably know, file parsing vulnerabilities are very common, and even though the number of such bugs has dropped significantly in Microsoft products, in the past we had many. Thankfully, the SDL's fuzzing requirements have significantly helped reduce the number of parsing-related vulnerabilities in our products.
As I mentioned, the vulnerabilities are not in Symantec code; they are in dependencies, in DLLs provided by another company. The SDL refers to these as "giblets," a term coined by Steve Lipner, a Senior Director at Microsoft and my co-author on "The Security Development Lifecycle." Giblets are of real concern because they are pieces of code that are used by your product but that you did not produce, and hence have little, if any control over. In short, if there's a security bug in a giblet you use, you have a security bug too. Symantec acknowledged this issue in its advisory:
"Symantec engineers have worked with (the third-party vendor) to identify these vulnerabilities and are working to update the affected module."
One of the hallmarks of a giblet is that they often affect more than one product, and sure enough, the same is true of these bugs; the same bugs affect IBM's Lotus Notes 7.0.2 and some other products too.
Now to the bugs themselves. I looked at four of the parser bugs as they affected IBM's Lotus Notes:
I would supply a CVE number for each of these, but it appears none have been assigned. However, all of these bugs are explained in detail at the vuln.sg Web site, and include an assembly-level analysis, which I used to determine the offending code, and sample exploit code.
The WPD bug is due to an integer overflow:
... it is possible to cause more than 2400 bytes to be copied from the WordPerfect file into the stack buffer. This overwrites the saved EIP and SEH, and can be exploited for arbitrary code execution
Could the SDL have caught this bug? Probably, either through fuzzing, code inspection or static-analysis. All of which are SDL requirements. With that said, integer overflows can be hard to spot.
This bug is caused by an insecure call to lstrcpy:
In several places within the DLL, the unsafe "lstrcpy()" function is used to copy each line read from the file into fixed sized stack and heap buffers
There is a very high probability that the SDL would catch this because lstrcpy (and all its evil brethren) are on the Banned API list. We have seen bugs that do not affect Windows Vista because of banned API removal, one such example is MS06-078 in Windows Media Player. The SDL's Banned API removal requirement has proven to be very effective.
Like the .SAM bug, this bug is an insecure call to a string copy function, in this case the strcpy and strcat duopoly. Again, banned API removal would probably have caught this.
The DOC bug is due to an incorrect call to memcpy():
The "memcpy()" function expects a length value to be supplied to determine the number of bytes that will be copied into the destination buffer.
Could the SDL have caught this? Possibly, but I would err on the side of possibly not. With that said, we are now heavily focused on memcpy-related bugs as a result of having issued five memcpy-related security bulletins in the past few years. Examples include:
Bugs in memcpy() appear to be more common these days; in fact, MIT's implementation of the Kerberos v5 authentication protocol had two remote root memcpy-related bugs recently:
There is no indication which compiler is used to compile these DLLs, but it looks like none have stack-based buffer overrun detection defense (such as the Visual Studio C++ /GS flag) or exception handler defenses (such as the Microsoft Link /SAFESEH flag) - both of which are SDL requirements. I also assume that the code is not linked with No-Execute (/NXCOMPAT), which is also an SDL requirement.
Bugs are interesting, you can learn a lot from your own bugs, but also from the bugs in other products. From an SDL perspective, there is nothing new about any of these vulnerabilities. It also appears that the DLLs are not compiled or linked with any other defenses. If I had my way they would be SDL compliant, and have as many defenses as possible as the parser code is an inch away from the Internet, and is used in a mission critical defensive position. What's interesting to me is how many other products out there consume these giblets? Because those products have security bugs too!