Dark Reading is part of the Informa Tech Division of Informa PLC

This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them.Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.

Risk

12/19/2008
10:57 PM
George V. Hulme
George V. Hulme
Commentary
50%
50%

Has Microsoft's Trustworthy Computing Got Us Anywhere?

As we noted earlier this week, Microsoft learned of a vulnerability in IE 7 on "Patch Tuesday," Dec. 9, and had a fix published for download eight days later. Now, Microsoft's Michael Howard, from the security engineering team, takes an interesting look at the lessons learned.

As we noted earlier this week, Microsoft learned of a vulnerability in IE 7 on "Patch Tuesday," Dec. 9, and had a fix published for download eight days later. Now, Microsoft's Michael Howard, from the security engineering team, takes an interesting look at the lessons learned.Building, testing, and releasing a patch, especially a patch that affects Internet Explorer that runs on all supported versions of Windows -- in about a week -- meant there were some software engineers working a string a very long days to get the patch out. No small effort, I'm sure.

But the question remains: how do flaws of this magnitude get into the final product? It's been since 2002 when Bill Gates issued that now famous e-mail that demanded change. (Which I covered in this news story.)

If you give even a cursory read of Howard's post from yesterday, building flawless software is challenging stuff. More challenging than most realize.

Howard first described the nature of the flaw, in technical details that are beyond the scope of this blog. Essentially, the flaw (which would allow attackers to remotely infiltrate at-risk systems by having users do no more than surf to the wrong URL), was an invalid pointer dereference in the MSHTML.DLL library used for data binding. Attackers would be able to exploit the way code is handled when a certain type of binding object was released, and a time-of-check-time-of-use (TOCTOU) programming error would result.

But why wasn't this error found during development, or quality assessment? Microsoft has a rather extensive Secure Development Lifecycle (SDL) in place, as the company likes to often tell us about. Howard explains why, and in doing so, we get a real-world peek into Microsoft's Secure Development Lifecycle (SDL).

During the code analysis and review phase, TOCTOU errors are tough to find, in part because developers weren't necessarily trained to find this specific bug. "We teach memory corruption issues, and issues with using freed memory blocks; but we do not teach memory-related TOCTOU issues," Howard explains in his post. And it's a condition that will soon change: "We will update our training to address this."

That type of candor is so rare in the software industry, and is sorely needed. "We had this system in place that didn't catch this condition, and we're going to fix it" is not something you hear from many vendors in IT.

Note to software developers: your customers appreciate transparency, and when you provide it, they'll be more inclined to trust you. Apple, for instance, has never publicly explained to anyone (not that I'm aware) the details of how it develops secure software. And in this obfuscation we all lose. Perhaps Apple has found some superior ways of handling certain security-related development techniques that, if they were to be shared with other developers, would benefit us all with more secure software. Then there's the flip side: maybe the security process Apple has in place is arcane, and that's why we're seeing more flaws and larger patches coming from Cupertino. We just don't know what reality is.

My apologies for the digression.

Back to the MS08-078 related bug and Microsoft's SDL:

Howard also explained that during the code analysis and review process, the company's normal fuzz testing (using software tools to find software bugs) wouldn't necessarily have worked because there has been no fuzzer test case created for this specific code.

So, there you have it, in the developing stage: developers were not made formally aware of this type of flaw, and fuzzing tools didn't have the right test-cases built to find it. Both conditions are probably because this type of attack never registered on the radar screen before.

He also explained how there are many defenses, to different degrees, within various versions of Windows. But because of the nature of this flaw, only a handful mattered. For instance, a certain switch (-GS) is mandated to be run when Microsoft code is compiled -- but this only works against stack overruns, not TOCTOU flaws. Also, both IE7 and IE8 have methods to terminate corrupted heaps, but this was not a corrupted heap attack. Next up, he explains how ASLR and NX (which are good at stopping certain types of memory attacks) could mitigated attacks on this flaw, but maybe not entirely defeat them.

This shows that we all, naturally, when conducting security training and testing tend to focus on the flaws that are perceived to pose the greatest risk because of the nature of the vulnerability, or the popularity of attackers exploiting them. Oftentimes organizations gauge this risk by both the potential impact of a successful attack, and the popularity of the "hacking" community to exploit it. But when developers focus on driving certain types of bugs to extinction, and defensive tools make certain types of attacks more difficult, attackers will move their attention elsewhere. Perhaps to (until now) relatively obscure TOCTOU attacks.

That's why, no matter how hard vendors try, situations like this are bound to continue for a long time, from time to time.

That brings us to IE 7 and IE 8 running on Vista in protected mode. It's my opinion that Protected Mode does an elegant job at protecting operating system resources from attack. As Howard notes: "When the exploit code runs, it's running at low integrity because IE runs at low integrity, and this means the exploit code cannot write to higher integrity portions of the operating system, which is just about everywhere!"

For our server platforms, Windows Server 2003 and Windows Server 2008, Internet Explorer Enhanced Security Configuration also prevents the exploit from working because the vulnerable code is disabled."

Howard concludes that you'll never get code 100% "right." And on this

I agree: there are just too many inter-connected parts, with each having its own set of springs, gears, and levies they interact with. Which brings us to the headline question: Has Microsoft gotten anywhere with its Trustworthy Computing initiative?

I think Internet Explorer 7 and higher, running in protected mode on Vista, is the most secure browsing experience Microsoft has ever created. And when it comes to software development practices, the company has come a long way since Gates' company-wide e-mail sent to every employee in the company, nearly seven years ago. In addition, I'm more comfortable with the Microsoft that has grown to be more collaborative with the IT industry and information security community, and the Microsoft that is more transparent about its mistakes.

Comment  | 
Print  | 
More Insights
Comments
Newest First  |  Oldest First  |  Threaded View
DevSecOps: The Answer to the Cloud Security Skills Gap
Lamont Orange, Chief Information Security Officer at Netskope,  11/15/2019
Attackers' Costs Increasing as Businesses Focus on Security
Robert Lemos, Contributing Writer,  11/15/2019
Register for Dark Reading Newsletters
White Papers
Video
Cartoon Contest
Write a Caption, Win a Starbucks Card! Click Here
Latest Comment: This comment is waiting for review by our moderators.
Current Issue
Navigating the Deluge of Security Data
In this Tech Digest, Dark Reading shares the experiences of some top security practitioners as they navigate volumes of security data. We examine some examples of how enterprises can cull this data to find the clues they need.
Flash Poll
Rethinking Enterprise Data Defense
Rethinking Enterprise Data Defense
Frustrated with recurring intrusions and breaches, cybersecurity professionals are questioning some of the industrys conventional wisdom. Heres a look at what theyre thinking about.
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2019-16860
PUBLISHED: 2019-11-19
Code42 app through version 7.0.2 for Windows has an Untrusted Search Path. In certain situations, a non-administrative attacker on the local machine could create or modify a dynamic-link library (DLL). The Code42 service could then load it at runtime, and potentially execute arbitrary code at an ele...
CVE-2019-16861
PUBLISHED: 2019-11-19
Code42 server through 7.0.2 for Windows has an Untrusted Search Path. In certain situations, a non-administrative attacker on the local server could create or modify a dynamic-link library (DLL). The Code42 service could then load it at runtime, and potentially execute arbitrary code at an elevated ...
CVE-2014-5118
PUBLISHED: 2019-11-18
A Security Bypass Vulnerability exists in TBOOT before 1.8.2 in the boot loader module when measuring commandline parameters.
CVE-2019-12422
PUBLISHED: 2019-11-18
Apache Shiro before 1.4.2, when using the default "remember me" configuration, cookies could be susceptible to a padding attack.
CVE-2012-4441
PUBLISHED: 2019-11-18
Cross-site Scripting (XSS) in Jenkins main before 1.482 and LTS before 1.466.2 allows remote attackers to inject arbitrary web script or HTML in the CI game plugin.