Risk
8/24/2011
10:51 AM
Connect Directly
RSS
E-Mail
50%
50%

Microsoft's Vista Hacker Speaks: 7 Lessons Learned

Chris Paget served on the "final security review" team that assessed Vista before release. Check out what he learned about software hardening.

Top Features Absent From Windows 7
(click image for larger view)
Slideshow: Top Features Absent From Windows 7
If you're a Microsoft conspiracy theorist seeking a smoking gun over Redmond's security practices, prepare to be disappointed. In so many words, that was the message delivered by security expert Chris Paget of Recursion Ventures--job title: chief hacker--who five years ago was part of a handpicked "final security review" team called in to assess Microsoft Vista for security defects on the eve of its release.

Vista's developers had expected their code to be near-perfect. Thanks to the efforts of Paget--a self-professed Unix aficionado--the release of Vista was delayed, as the three-month code review tripled in personnel size and project duration.

Speaking earlier this month at Black Hat, a UBM TechWeb event in Las Vegas, just days after his five-year nondisclosure agreement (NDA) with Microsoft expired, Paget outlined the code review's security lessons for Microsoft, and what other independent software vendors can learn too:

1. Hire Outsiders: Microsoft hired several outside security experts to review the Vista code for bugs, then supported them. "We had full access to everything," said Paget. "We had a really spectacular team working with us at Microsoft, where we got anything we needed--documentation, source code, or a [response from a] developer who wasn't returning our calls because we had asked tough questions." To his knowledge, this was the first time Microsoft had used outside reviewers to assess an operating system code base.

2. Price Bugs: Is it worth hiring a code-review team before shipping a product? To find out, calculate the cost of every pre-production bug found in code. "At the time, Microsoft had come out with an internal study that said it was $250,000 to fix a security bug" in production code, said Paget. That cost included numerous factors, comprising not just software engineering time, but also the cost of the bug to Microsoft's reputation.

3. Commoditize Code Review: Knowing how much it costs to fix a bug in production code gives software developers a business case for ensuring bugs never make it into product releases. Hypothetically speaking, if Microsoft spent $1 million for a code review that unearthed five new bugs, then it saved money.

4. Build A Bug Bar: As part of its security development lifecycle (SDL), Microsoft maintains a document known as the Bug Bar, specifying how to classify any given bug. This was relevant because the Bug Bar clearly stated that certain types of bugs, if not fixed before Vista was ready to ship, would result in their related feature being struck from Vista. Developers took notice of that clause.

5. Model Threats: Microsoft required developers to "threat model" Vista features, resulting in "some superb documentation," said Paget. "We had folks on the team, all they were doing was sitting and reviewing threat models for months and months and months." By spotting whether two features might react in bad way, developers could then resolve how they interacted.

6. Search For "Bug": The code review team searched for profanity in Vista code base comments and "found surprisingly little." But whenever they discovered a comment along the lines of "bug bug" or "fix me," they paid careful attention.

7. Use Secure Development: ""Microsoft's security process, in my opinion is spectacular," said Paget. "I strongly recommend it to everyone I talk to, Microsoft has really set the gold standard about how to implement SDL for a large software product. Please quote me on that."

The vendors, contractors, and other outside parties with which you do business can create a serious security risk. Here's how to keep this threat in check. Also in the new, all-digital issue of Dark Reading: Why focusing solely on your own company's security ignores the bigger picture. Download it now. (Free registration required.)

Comment  | 
Print  | 
More Insights
Register for Dark Reading Newsletters
White Papers
Cartoon
Current Issue
Dark Reading Must Reads - September 25, 2014
Dark Reading's new Must Reads is a compendium of our best recent coverage of identity and access management. Learn about access control in the age of HTML5, how to improve authentication, why Active Directory is dead, and more.
Flash Poll
Video
Slideshows
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2012-5619
Published: 2014-09-29
The Sleuth Kit (TSK) 4.0.1 does not properly handle "." (dotfile) file system entries in FAT file systems and other file systems for which . is not a reserved name, which allows local users to hide activities it more difficult to conduct forensics activities, as demonstrated by Flame.

CVE-2012-5621
Published: 2014-09-29
lib/engine/components/opal/opal-call.cpp in ekiga before 4.0.0 allows remote attackers to cause a denial of service (crash) via an OPAL connection with a party name that contains invalid UTF-8 strings.

CVE-2012-6107
Published: 2014-09-29
Apache Axis2/C does not verify that the server hostname matches a domain name in the subject's Common Name (CN) or subjectAltName field of the X.509 certificate, which allows man-in-the-middle attackers to spoof SSL servers via an arbitrary valid certificate.

CVE-2012-6110
Published: 2014-09-29
bcron-exec in bcron before 0.10 does not close file descriptors associated with temporary files when running a cron job, which allows local users to modify job files and send spam messages by accessing an open file descriptor.

CVE-2013-1874
Published: 2014-09-29
Untrusted search path vulnerability in csi in Chicken before 4.8.2 allows local users to execute arbitrary code via a Trojan horse .csirc in the current working directory.

Best of the Web
Dark Reading Radio
Archived Dark Reading Radio
In our next Dark Reading Radio broadcast, we’ll take a close look at some of the latest research and practices in application security.