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.

 

Recommended Reading:

Comment  | 
Print  | 
More Insights
Comments
Newest First  |  Oldest First  |  Threaded View
COVID-19: Latest Security News & Commentary
Dark Reading Staff 8/10/2020
Pen Testers Who Got Arrested Doing Their Jobs Tell All
Kelly Jackson Higgins, Executive Editor at Dark Reading,  8/5/2020
Researcher Finds New Office Macro Attacks for MacOS
Curtis Franklin Jr., Senior Editor at Dark Reading,  8/7/2020
Register for Dark Reading Newsletters
White Papers
Video
Cartoon Contest
Current Issue
Special Report: Computing's New Normal, a Dark Reading Perspective
This special report examines how IT security organizations have adapted to the "new normal" of computing and what the long-term effects will be. Read it and get a unique set of perspectives on issues ranging from new threats & vulnerabilities as a result of remote working to how enterprise security strategy will be affected long term.
Flash Poll
The Changing Face of Threat Intelligence
The Changing Face of Threat Intelligence
This special report takes a look at how enterprises are using threat intelligence, as well as emerging best practices for integrating threat intel into security operations and incident response. Download it today!
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2020-17476
PUBLISHED: 2020-08-10
Mibew Messenger before 3.2.7 allows XSS via a crafted user name.
CVE-2020-9525
PUBLISHED: 2020-08-10
CS2 Network P2P through 3.x, as used in millions of Internet of Things devices, suffers from an authentication flaw that allows remote attackers to perform a man-in-the-middle attack, as demonstrated by eavesdropping on user video/audio streams, capturing credentials, and compromising devices.
CVE-2020-9526
PUBLISHED: 2020-08-10
CS2 Network P2P through 3.x, as used in millions of Internet of Things devices, suffers from an information exposure flaw that exposes user session data to supernodes in the network, as demonstrated by passively eavesdropping on user video/audio streams, capturing credentials, and compromising devic...
CVE-2020-9527
PUBLISHED: 2020-08-10
Firmware developed by Shenzhen Hichip Vision Technology (V6 through V20, after 2018-08-09 through 2020), as used by many different vendors in millions of Internet of Things devices, suffers from buffer overflow vulnerability that allows unauthenticated remote attackers to execute arbitrary code via ...
CVE-2020-9528
PUBLISHED: 2020-08-10
Firmware developed by Shenzhen Hichip Vision Technology (V6 through V20), as used by many different vendors in millions of Internet of Things devices, suffers from cryptographic issues that allow remote attackers to access user session data, as demonstrated by eavesdropping on user video/audio strea...