Microsoft Security RC Blog

Hi everyone,

Since we released Security Advisory 2269637 on August 23, we've continued to conduct an investigation not only into our own affected products, but also into how we can best help to protect customers given DLL preloading also affects some third-party applications. We'd like to provide an update on our investigation.

First, I want to be clear that Microsoft plans to address those of our products affected by this issue in the most appropriate way for customers. This will primarily be in the form of security updates or defense-in-depth updates. Also, due to the fact that customers need to click through a series of warnings and dialogs to open a malicious file, we rate most of these vulnerabilities as important.

One of the goals we have at Microsoft is to make it easy for developers to create secure applications on our platform. As we stated in our previous blog post, DLL preloading is a well-known class of vulnerabilities and we have had guidance for developers in place for quite some time. We have recently updated that guidance to provide more clarity.

Even with improved guidance, we recognize that it may take quite a bit of time for all affected applications to be updated and for some, an update may not be possible. With the advisory, we released a tool to help customers protect their systems (see KB 2264107). This tool provides a framework for customers to modify the behavior of the DLL search path algorithm and essentially block unsafe DLL loading. When installed, this tool still needs to be configured in order to block malicious behavior, and customers have asked us for our recommended setting. As a result, our Security Research & Defense team has written a detailed blog post on this topic and has worked with our Microsoft Fix-it team to develop a Fix-it to enable our recommended setting which blocks most network-based attack vectors. (Please note that the tool needs to be installed prior to enabling the Fix-it.)

Many enterprise customers have asked us to make it easier for them to deploy this tool. As a result, we are working with the Windows Update (WU) team to add the tool to the WU catalog. This will make it easier for those running Windows Server Update Services (WSUS) to deploy. We are working to have that solution in place within the next couple of weeks. We are also considering releasing this solution more broadly via WU as a defense-in-depth update for all customers in an "off by default" state. We will share more information through the MSRC blog as our plans are solidified.

Customers should note that the tool is limited to protecting against DLL preloading only and does not protect against .exe files that do not properly load files via a fully qualified path and developers will be required to update those applications accordingly.

Thank you,

Jerry Bryant
Group Manager, Response Communications

Overview

Today we released Microsoft Security Advisory 2269637. This is different from other Microsoft Security Advisories because it's not talking about specific vulnerabilities in Microsoft products. Rather, this is our official guidance in response to security research that has outlined a new, remote vector for a well-known class of vulnerabilities, known as DLL preloading or "binary planting" attacks.  We are currently conducting a thorough investigation into how this new vector may affect Microsoft products. As always, if we find this issue affects any of our products, we will address them appropriately.

Additionally, today we are providing a defense-in-depth update that customers can deploy that will help protect against attempts to exploit vulnerable applications through this newly identified vector. Finally, we are using our strong connections with researchers and partners in the industry to help address this new class of vulnerability. Our Microsoft Vulnerability Research program has been working to coordinate communication between the researcher who first brought this new vector to us and other application developers who are affected by this issue.

Technical Background

What this new research demonstrates is a new remote vector for DLL preloading attacks. These attacks are not new or unique to the Windows platform. For instance, PATH attacks that are similar to this issue constitute some of the earliest class of attacks against the UNIX operating system. The attack focuses on tricking an application into loading a malicious library when it thinks it's loading a trusted library. For this to succeed, the application has to call the trusted library by name instead of properly using its full path (for example, calling dllname.dll rather than C:\Program Files\Common Files\Contoso\dllname.dll). The attacker then has to place a malicious copy of the library in a directory that the system will search to locate the library and have that be a directory it will search before the directory where the trusted library actually is. For example, if an attacker knows that the application simply calls for dllname.dll (rather than using the full path) and it will look for dllname.dll in the current working directory before looking in C:\Program Files\Common Files\Contoso\. Then if the attacker can plant a malicious copy of dllname.dll in the current working directory, the application will load it first executing the attacker's code in the application's security context.

PATH or DLL preloading attacks have so far required the attacker to plant the malicious library on the local client system. This new research outlines a way an attacker could levy these attacks by planting the malicious library on a network share. In this scenario, the attacker would create a data file that the vulnerable application would open, create a malicious library that the vulnerable application would use, post both of them on a network share that the user could access, and convince the user to open the data file. At that point, the application would load the malicious library and the attacker's code would execute on the user's system.

Because this is a new vector, rather than a new class of vulnerability, the existing best practices that protect against this class of vulnerability, automatically protect against this new vector: ensuring that applications make calls to trusted libraries using full path names.

While the best protection is following best practices, we are able to provide an additional layer of defense by offering a tool that can be configured to disable the loading of libraries from network shares. In particular, because this is altering functionality, we encourage customers to evaluate this tool before deploying it. As part of your evaluation, we encourage you to review the information at the Security Research and Defense (SRD) blog.

We will continue our work with the researchers and the industry to identify and address vulnerable applications. And as always, we will update you with any new information we have through our security advisories, security bulletins and the MSRC weblog as appropriate.

Thanks

Christopher

Hello,

Today we published the Questions & Answers from the August 2010 Security Bulleting webcast. We answered a total of 17 questions concerning the March bulletins and open Security Advisories. No particular themes emerged from the questions but there were some good ones so please review them.

The video covers the core part of the presentation Adrian Stone and I gave during the webcast. We talk about the 14 bulletins for August and Security Advisory 2264072.

Please join us for our next scheduled webcast where Adrian and I, along with a room full of subject matter experts, will present on the Security Bulletins for September and try to answer all your questions live.

Date: Wednesday, September 15, 2010
Time: 11:00 a.m. PDT
Registration: https://msevents.microsoft.com/CUI/WebCastEventDetails.aspx?EventID=1032454433&EventCategory=4&culture=en-US&CountryCode=US  

Thanks!

Jerry Bryant
Group Manager, Response Communications

   Other Viewing Options:

• Windows Media Video (WMV)
• Windows Media Audio (WMA)
• iPod Video (MP4)
• MP3 Audio
• High Quality WMV (2.5 Mbps)
• Zune Video (WMV)

Hi everyone,

Yesterday we tweeted to let customers know that we were investigating a publicly disclosed vulnerability in the Windows Kernel-mode drivers (win32k.sys) affecting all supported operating systems. We are not aware of attacks that try to use the reported vulnerability or of any customer impact at this time. Today we have more information, as well as a planned course of action.

While most in the industry reported this as a low-severity vulnerability, it generated quite a bit of attention, and as always, we started our investigation as soon as we became aware of the issue. We have not yet reported on this issue because it's important we're thorough in our investigations, and there were a couple of possible vectors that we wanted to validate (or invalidate as the case may be) before we commented or defined a course of action.

As a result, we are now able to report that this is a local elevation of privilege vulnerability only. This type of issue allows attackers to gain system-level privileges after they have already obtained an account on the target system.  For this issue to be exploited, an attacker must have valid log-on credentials on the target system and be able to log on locally, or must already have code running on the target system. The vulnerability cannot be exploited remotely, or by anonymous users. 

We will not be releasing a security advisory for this issue, but it will be included in a future security update. We will continue monitoring the threat landscape and alert customers if anything changes.

Thanks to Dustin Childs and the rest of our security engineering team for their quick and thorough work to determine the cause and extent of this issue across platforms!

Thanks,

Jerry Bryant
Group Manager, Response Communications

Hello all. As part of our usual cycle of monthly updates, today Microsoft is releasing 14 security bulletins, addressing 34 vulnerabilities. Eight of those bulletins have a Critical severity rating, and we consider four of those to be high-priority deployments:

• MS10-052 This bulletin resolves a privately reported vulnerability in Microsoft's MPEG Layer-3 audio codecs. The vulnerability could allow remote code execution if a user opens a specially crafted media file or receives specially crafted streaming content from a Web site. An attacker who successfully exploited this vulnerability could gain the same user rights as the logged-on user.

• MS10-055 This bulletin resolves a privately reported vulnerability in Cinepak Codec, which is used by Windows Media Player to support the .avi audiovisual format. The vulnerability could allow remote code execution if a user opens a specially crafted media file, or receives specially crafted streaming content from a Web site. An attacker who successfully exploited this vulnerability could gain the same user rights as the logged-on user.

• MS10-056 This bulletin resolves four privately reported vulnerabilities in Microsoft Office. The most severe vulnerabilities could allow remote code execution if a user opens or previews a specially crafted RTF e-mail message. An attacker who successfully exploited any of these vulnerabilities could gain the same user rights as the local user. Windows Vista and Windows 7 are less exploitable due to additional heap mitigation mechanisms in those operating systems.

• MS10-060 This bulletin resolves two privately reported vulnerabilities, both of which could allow remote code execution, in Microsoft .NET Framework and Microsoft Silverlight.

Currently none of the vulnerabilities addressed has been observed under exploit in the wild. In the following video, Jerry Bryant and Adrian Stone talk about why these four are at the top of our priority list:

More listening and viewing options:

• Windows Media Video (WMV)
• Windows Media Audio (WMA)
• iPod Video (MP4)
• MP3 Audio
• High Quality WMV (2.5 Mbps)
• Zune Video (WMV)

The six other bulletins offered this month are rated Important. Two of the Important-level bulletins, MS10-047 and MS10-048, are Windows Kernel updates.

As always, Microsoft recommends that customers test and deploy all security updates as soon as they can.

For a closer look at some of the issues involved in these bulletins, our Security Research & Defense (SRD) team writes about MS10-048, MS10-049, and MS10-054 today on its blog.

We're also releasing Security Advisory 2264072 with this update. This advisory addresses the potential for attacks that leverage the Windows Service Isolation feature to gain elevation of privilege. In turn, the release of MS10-049 closes Security Advisory 977377, which described a spoofing vulnerability addressed in today's release. When early investigation revealed that this vulnerability is an industry-wide problem, Microsoft worked on a coordinated response with our partners in the Internet Consortium for Advancement of Security on the Internet (ICASI). A new standard was developed, RFC 5746, which allows developers of both client and server applications to address this vulnerability.

More information about the security updates can be found on the Microsoft Security Bulletin summary webpage.  Our Exploitability Index provides additional information to help customers prioritize deployment of the monthly security bulletins.

On August 2, we released MS10-046 out of band in response to a new zero-day vulnerability being exploited by the Stuxnet family of malware. This month, we have added Stuxnet and several other malware to the Malicious Software Removal Tool (MSRT) in order to help clean up systems that may have been impacted. Here's the full list of new malware being added:

• Win32/Stuxnet
• Win32/CplLnk
• Worm:Win32/Vobfus.gen!A
• Worm:Win32/Vobfus.gen!B
• Worm:Win32/Vobfus.gen!C
• Worm:Win32/Vobfus!dll
• Worm:Win32/Sality.AU
• Virus:Win32/Sality.AU
• TrojanDropper:Win32/Sality.AU

Please join the monthly technical webcast to learn more about the August 2010 security bulletin release. The webcast is scheduled for Wednesday, August 11, 2010 at 11:00 a.m. PDT (UTC -7). Registration is available here.

Reminder: You can follow the team for late breaking news and updates on the threat landscape here: @MSFTSecResponse.

Thanks!

Angela Gunn
Security Response Communications Manager

Hello; I'm Angela Gunn and I'm new to the Response Communications team. Today we're releasing our advance notification for the August security bulletin release, which is scheduled for Tuesday, August 10. This month's release is composed of 14 bulletins addressing 34 vulnerabilities in Windows, Microsoft Office, Internet Explorer, SQLMSXML, and Silverlight. Eight of the bulletins carry a Critical severity rating, and six are rated Important.

As always, we recommend that customers review the ANS summary page for more information and prepare for the testing and deployment of these bulletins as soon as possible.

For those who keep track of such things, this will be the most bulletins we have ever released in a month; we have released 13 bulletins on a couple of occasions. However, in total CVE count, this release ties with June 2010, so there's no new record there. Please join Adrian Stone and Jerry Bryant for a public webcast on Wednesday. We'll go into detail about all the bulletins and answer questions live on the air. Register at the link below:

Date: Wednesday August 11
Time: 11:00 a.m. PDT (UTC -7)
Registration: https://msevents.microsoft.com/CUI/WebCastEventDetails.aspx?EventID=1032454431

Thanks,

Angela Gunn
Security Response Communications Manager

Follow us on Twitter: @MSFTSecResponse

Hello -

During today's webcast our team of technical experts answered over fifty questions regarding the August 2010 Out-of-Band Security Release update questions.   Click here to review the entire list of questions and answers from today's Out-of-Band webcast Q&A page.

Also, here is the link to the Q&A index page for your review -  in case you wanted to view any of the past 12 webcast Q&A's.

As always, customers experiencing issues with the installation of today's security update should contact our Customer Service and Support group:

• Customers in the U.S. and Canada can receive technical support from Microsoft Product Support Services at 1-866-PCSAFETY. There is no charge for support calls that are associated with security updates.
• International customers can receive support from their local Microsoft subsidiaries. There is no charge for support that is associated with security updates. For more information about how to contact Microsoft for support issues, visit the International Support Web site.

We look forward to your joining us during our regular monthly webcast on August 10, 2010.  Click here to register.

Thanks!

Christopher Budd

Sr. Security Response Communications Manager at Microsoft

Hello,

As we announced on Friday, today we released Security Bulletin MS10-046 out-of-band to address a vulnerability in Windows. This security update addresses a vulnerability in the handling of shortcuts that affects all currently supported versions of Windows XP, Vista, Windows 7, Windows Server 2008 and Windows Server 2008 R2. As our colleagues over in the MMPC have noted, several families of malware have been attempting to attack this vulnerability. The security update protects against attempts to exploit this issue.

For customers using automatic updates, this update will automatically be applied once it is released. Customers not using automatic updates should download, test and deploy this update as quickly as possible.

As we do with every bulletin release, we will be hosting a webcast to address your questions today at 1PM Pacific Time. Register now.

Thanks,

Christopher Budd

Sr. Security Response Communications Manager at Microsoft

Today we're announcing plans to release a security update to address the vulnerability discussed in Security Advisory 2286198 on Monday, August 2, 2010 at or around 10 AM PDT. 

We are releasing the bulletin as we've completed the required testing and the update has achieved the appropriate quality bar for broad distribution to customers. Additionally, we're able to confirm that, in the past few days, we've seen an increase in attempts to exploit the vulnerability. We firmly believe that releasing the update out of band is the best thing to do to help protect our customers.

Our colleagues over in the Microsoft Malware Protection Center (MMPC) have more details about what they've seen in the threat environment.

As always, we'll provide additional information as it is available.

Finally, as always, we'll hold a special edition of the bulletin release webcast on Monday, August 2, 2010 at 1:00 PM PDT. If you are interested in attending the webcast, click here to sign up.

Thanks,

Christopher Budd

Sr. Security Response Communications Manager at Microsoft

Two years ago, in front of a standing-room only crowd here at Black Hat, we introduced three new information sharing programs as well as the concept of Community-Based Defense. The underlying concept shared by all three programs was simple-collaboration will be key to preventing and defending against online crime going forward; no one company, individual or technology can do it alone. The call to action was bold-put aside competitive and philosophical differences and move beyond our individual boundaries to work together to help improve and protect the broader security ecosystem. The reaction-applause!

We all know Black Hat can be a tough crowd, and wearing the blue badge can at times amplify that - making the positive response really pleasant. But it wasn't altogether unexpected.  Each of the then-new programs-the Microsoft Active Protections Program (MAPP), Microsoft Exploitability Index and Microsoft Vulnerability Research (MSVR)-were fueled by, and designed to address, customer needs.  And recognizing the collaborative nature of two of the programs, we'd spent months getting feedback and support within the community, from customers to vendors to researchers, to get into a position to make the announcements that day. 

Today, the MSRC released its second annual progress report on those programs-"Building a Safer, More Trusted Internet through Information Sharing"-and we're excited to share the results.

Some highlights:

• MAPP now has 65 members worldwide, providing protections for hundreds of millions of customers.
• MSVR identified and privately coordinated vulnerabilities with 32 and 19 vendors in the first and second years of operations respectively.
• Of the 349 Exploitability Index ratings provided for vulnerabilities resolved by Microsoft, there has been only one revision, which involved a reduction in risk assessment severity.

Speaking of the success and impact of MAPP, we couldn't be more thrilled with the announcement today that Adobe Systems Incorporated will begin sharing early warning details on their vulnerabilities through MAPP beginning this fall. Two years ago, there was broad feedback throughout the industry-from analysts, customers, and partners-that MAPP was a game-changer, shifting competitive advantage away from the bad guys (criminals, attackers) to the good guys (protection providers, customers). For the first time, protection providers were able to operate together on a massive scale, developing and preparing protections for their customers to be made available upon release of Microsoft security vulnerabilities -- and ahead of the exploits developed by attackers. Today, we believe the same game has been raised a level with Adobe helping to advance protection time, giving an upper hand to the global network of defenders in the battle against online crime.

Many of you have already read Matt Thomlinson's introduction last week of our new policy of coordinated vulnerability disclosure and Katie Moussouris' expansion on the concept and the need for reframing the community's approach and mindset from the subjective language of "responsible" to the collaborative label of "coordinated." I don't intend to rehash that here, except to say that we look forward to continuing the dialogue on this new policy at Black Hat and beyond. This move didn't happen overnight as we believe it is reflective of a broader groundswell within the community that's been underway for some time. We're encouraged by the overwhelming volume of support behind the shift as evidenced in Katie's post and in interactions and response since then.

Even with more concerted attention on community-based defense and this growing sense of shared responsibility throughout the security community, attackers will still continue to case systems and applications looking for vulnerabilities. The stakes are high and criminals won't relent.  So today, we're also announcing the Enhanced Mitigation Experience Toolkit (EMET). 

EMET is a free tool that provides a way for IT professionals to add some of the latest security mitigations -- such as DEP, mandatory ASLR and export address table (EAT) filtering -- to software to protect against exploits of vulnerabilities.  It helps harden existing applications from current exploit techniques without requiring any recoding. Look for an SRD blog post in August announcing availability of the new toolkit on the Microsoft Download Center.

More details on each of these announcements can be found at our Black Hat Press Site: http://www.microsoft.com/presspass/events/blackhat/.

Every Black Hat is different, but year after year one of the highlights of the show for Microsoft is continuing the conversation with researchers, partners and customers, and then acting on it. This is a community that is bound together by a common purpose-that is to improve the security landscape. It used to be enough to expect others to make that happen; but today, no one is exempt from helping to ensure the safety of the Internet. We're in this together, and we're better together. If you're at the show, pay us a visit at the booth or say hello when you see us; in any case, we look forward to hearing from you and continuing this work together.

Dave Forstrom, Director, Microsoft Trustworthy Computing

BH Landscape

Next week, many of us here will be heading down to Las Vegas for Black Hat.  The MSRC, and other teams in Microsoft, have been attending Black Hat for years.  In fact, we've been sponsoring the show for the last eight years-the last five as a platinum sponsor. Some might ask why? It's funny, I can actually remember back in my days as an officer protecting networks in the U.S. Air Force, questioning why Microsoft had such a presence at the show. As much as I'd like to say it's because of the weather (after all, most of us are over here in the rainy Northwest), or because it's the largest security conference out there (it's not), or even better, because we so look forward to getting our next Pwnie Award-the truth is it's none of the above. Well, maybe just a bit on the Pwnie. But the reality is that to us, Black Hat has always been a reflection of, and driven by, the community-likeminded people from all walks of life and professions with a shared interest in advancing the state of security. They come together to share ideas, advance thinking, network and collaborate, and ultimately learn from one another.  We feel connected to that and always look forward to being a part of it.

So with the show fast approaching, I've taken some time to reflect on where the Microsoft Security Response Center is currently and where we see ourselves going with respect to security. Specifically, I've been thinking a lot about three areas: 1) our work to address vulnerabilities in our software, 2) our work with the security community and 3) our philosophy on vulnerability disclosure. Given the fact that each of these topics have recently garnered interest and fueled discussion in the community and media, I thought I'd share my thoughts.

Vulnerabilities and Time to Fix

Some will say that we take too long to fix our vulnerabilities. But it isn't all about time-to-fix: Our chief priority with respect to security updates is to minimize disruption to our customers and to help protect them from online criminal attackers. These customers own and operate a diverse ecosystem of nearly a billion systems worldwide. It's humbling to think about the responsibility this entails and yet we embrace the challenge. Even in the face of that, our overall track record shows the window of vulnerability is being reduced and we have additional plans to improve.

The Microsoft Security Response Center (MSRC) receives more than 100,000 e-mail messages per year at secure@microsoft.com - that's nearly 275 per day or 11 per hour. This is filtered down to approximately 1,000 legitimate investigations per year. Once a vulnerability has been confirmed, a comprehensive examination is undertaken to ensure that the reported vulnerability is addressed, other vulnerabilities that might exist in related code are identified and addressed, and no new vulnerabilities or bugs are introduced during this process.

But why don't we commit to fixed timelines? Because it is important to consider the overall customer risk when focusing on updating software for security issues. Most security updates released by the MSRC will be rapidly deployed to hundreds of millions of systems worldwide helping to protect customers from attacks in a very short timeframe. And the software being updated is being used by hundreds of thousands of applications on all sorts of hardware in all sorts of scenarios. So it is imperative that the update has been rigorously engineered and tested in order to avoid creating any type of disruption to these systems. During this time, the MSRC monitors for signs that the vulnerability, or variants, are being used in active attacks. The MSRC does this by using comprehensive telemetry systems as well as data and information provided by customers and partners around the world, and the rest of the industry. This approach helps Microsoft balance between the potential urgency of releasing an update for a particular vulnerability and ensuring high confidence that the update will address the vulnerability, all of its variants and maintain the functionality and stability that customers expect from the affected products.

Many times the issue that the finder reported is an indication of other similar vulnerabilities in that area of code. And the original issue may not be the most complicated, or even the most likely to get used in attacks. Microsoft tries to address vulnerabilities and all of their variants in as few updates as possible because they cost enterprise customers time, effort and money to re-assess and deploy multiple updates for issues that could potentially be addressed in a single update. The time it takes to complete a comprehensive examination helps to ensure the number of security updates Microsoft releases and needs to re-release is kept to a minimum, thus reducing the costs and potential disruption to enterprise customers' operations. Due to the increase in quality that Microsoft has achieved over the last five years, some enterprise customers deploy security updates with little or no testing, and hundreds of millions of consumers continue to use the Automatic Update client on their systems to ensure that they stay protected automatically.

For the majority of issues, we are able to release high quality and comprehensive security updates to customers well before any indication of attacks, and well before they are disclosed publicly. However, there are exceptions. In some cases attacks result, and when that happens, we have to compress testing to release updates quickly. Also, when there are attacks, we release workarounds in days that can block these attacks even without the updates. Usually these take the form of a "FixIt" that can protect customers with one click or be easily deployed throughout the enterprise.

However, there are cases that take much longer. In fact, last year at Black Hat there was a security event dealing with a vulnerability in a library called "ATL" or "Active Template Library." That issue affected not only multiple Microsoft product versions, but also several 3rd party products and services. It took over a year to coordinate that release, and in the end, even the finders themselves understood and commented that with the complexity involved, taking over a year wasn't unreasonable. When seemingly simple security issues, such as a memory corruption bug, affect multiple different products, the coordination and calibration can drive longer timelines so no product, or customers of those products are left behind. And there have also been cases that are such deep architectural changes that they can take multiple years to fully resolve or may not be able to be resolved in some of our older products.  Usually these issues result from new threats emerging that product designs or assumptions couldn't anticipate.  Changing those assumptions for products that have been in market for several years does take time and coordination so customers and applications can work effectively with them.

Focusing on resolving security issues has and will always be a priority for us. And work to improve our processes will continue, but we must always strike a balance between timeliness and quality.

Working with the Security Community

The topic of how well Microsoft works with the security community is important to me personally, and to my team. Years ago, this was a very valid concern. I can remember being on the outside of Microsoft and watching researcher discussions noting how Microsoft wouldn't engage or was unresponsive. We've made dramatic changes on this front since the inception of Trustworthy Computing. At Microsoft we recognize, and appreciate, the unique value that security researchers play in identifying issues and helping the entire computing ecosystem improve from a security perspective. We also thank many in the community for their collaborative work over the years, and for nearly a decade we have demonstrated our commitment to working with them in an honest and transparent manner. We may not always agree on the severity and the amount of time it should take to develop and test an update that has to work with hundreds of millions of computers, but we do believe we're fair and open when working with researchers. It's not in our interest or the interest of our customers to behave any differently.

 Throughout the years we've seen researchers saying that if vendors really valued their work, we'd compensate them directly for the vulnerabilities they discover. That's a trend that's continued in recent weeks. We absolutely value the researcher ecosystem, and show that in a variety of ways. The most well-known is the fact that we acknowledge the researcher's work in our bulletins when a researcher has coordinated the release of vulnerability details with the release of a security update. And that's just the tip of the iceberg. We also work to make sure we can support the community's development by sponsoring and supporting nearly 50 security conferences in over 20 countries each year. 

Probably the community effort that started more of the deeper relationships we've built with researchers is our own little "hacker" conference we host at Redmond each year, called "BlueHat Security Briefings." Launched in 2004, this conference is aimed at bringing Microsoft security professionals and external security researchers together in a relaxed environment to promote the sharing of ideas, social networking and ultimately improving the security of Microsoft products. Key to the success of BlueHat and its benefit to our customers is the direct question-and-answer access that researchers get with the specific owners of the technology they're researching. In many cases, some of our direct competitors have sat on our stage at Microsoft and talked about problems in our products, directly to the folks that develop and manage them. And they've been able to get feedback on their research from the same folks as well.

The Shift to Coordinated Vulnerability Disclosure

If there's one area that has had had staying power in terms of driving polarized debate in the broader security community-as manifested in mainstream and social media this past month-it's in how to disclose vulnerability details.  Ideally, updates for those vulnerabilities are available for all customers before details are broadly available. This allows us to protect the end-users because they just get the updates automatically, and large Enterprises can analyze, prioritize and deploy updates to hundreds of thousands of systems quickly. When communication breakdowns and disagreements happen, resulting in vulnerability details disclosed by researchers before we release an update, those details are then used by criminals to attack our customers. The worst situation is when vulnerabilities aren't disclosed to the vendor at all, because then there's very little hope of broad protections ever getting released for all customers. 

Because of this range of situations, we also see a range of philosophies. Of course, Microsoft always supported the position that the best way to disclose issues is in a coordinated fashion, where details of the vulnerability are released in conjunction with an update that is broadly available for customers. This is known as "Responsible Disclosure." The term itself can be subjective because if either party doesn't abide by those terms, it is implied that they themselves are "irresponsible." Debate on this very issue of responsibility is understandable; however, it is important to remember that in the end we are dealing with customer safety issues - and we should all take that seriously. It is unfortunate these debates can make us lose focus on what is really important - protecting people using the Internet from harm.

Today, Matt Thomlinson, the general manager of Security at Trustworthy Computing, introduced a new disclosure philosophy Microsoft is adopting called Coordinated Vulnerability Disclosure http://blogs.technet.com/b/msrc/archive/2010/07/22/announcing-coordinated-vulnerability-disclosure.aspx .  Katie Moussouris, senior security strategist on the MSRC Ecosystem Strategy team, provides more information and insight on the necessity of this shift in disclosure philosophy and practice on the MSRC Ecosystem Strategy Team Blog http://blogs.technet.com/b/ecostrat/archive/2010/07/22/coordinated-vulnerability-disclosure-bringing-balance-to-the-force.aspx. You'll see from her post, we're not alone in acknowledging it is time for a change. Other vendors and researchers from the broader community of defenders are supportive and will be instrumental in making this shift a reality. So read the post, provide your feedback and then join us in making this an industry wide shift.

Now back to the catalyst for this post-Black Hat.  We're just a few days from the event itself and we'll likely see more themes develop once it kicks-off. But I hope the thoughts I've shared here provide some insights into our point of view on recent discussions in the community.

The realities of today's threat landscape point to a world that has shifted from a variety of participants with various motives to one of two sides-those who intend to harm or commit crime and those who intend to prevent harm and fight crime. As an industry and community, philosophical differences or competition aside, we should be in this together. Our own welfare as individuals and a collective community is at stake with unseen criminals who show no indication of backing down. It's our hope that this effort to shift to a shared responsibility of coordination and collaboration is something that is carried beyond Black Hat as we progress and evolve as a global community of defenders.

Hope to see you at Black Hat!

Mike Reavey
Director, MSRC

Today, Microsoft is announcing a shift in philosophy on how we approach the topic of vulnerability disclosure, reframing the practice of "Responsible Disclosure" to "Coordinated Vulnerability Disclosure."  In recognition of the endless debate between responsible disclosure and full disclosure proponents and its ability to detract from meaningful and productive industry collaboration and customer defense, we believe that the community mindset needs to shift, framing a key point - that coordination and collaboration are required to resolve issues in a way that minimizes risk and disruption for customers.

Coordinated Vulnerability Disclosure (CVD):   Newly discovered vulnerabilities in hardware, software, and services are disclosed directly to the vendors of the affected product, to a CERT-CC or other coordinator who will report to the vendor privately, or to a private service that will likewise report to the vendor privately. The finder allows the vendor an opportunity to diagnose and offer fully tested updates, workarounds, or other corrective measures before detailed vulnerability or exploit information is shared publicly. If attacks are underway in the wild, earlier public vulnerability details disclosure can occur with both the finder and vendor working together as closely as possible to provide consistent messaging and guidance to customers to protect themselves.

Responsibility is still imperative, but it is a shared responsibility across the community of security researchers, security product providers and other software vendors. Each member of this community of defenders plays a role in improving the overall security of the computing ecosystem.  

CVD does not represent a huge departure from the current definition of "responsible disclosure," and we would still view vulnerability details being released broadly outside these guidelines as putting customers at unnecessary levels of risk. However, CVD does allow for more focused coordination on how issues are addressed publicly. CVD's core principles are simple: vendors and finders need to work closely toward a resolution; extensive efforts should be made to make a timely response; and only in the event of active attacks is public disclosure, focused on mitigations and workarounds, likely the best course of action -- and even then it should be coordinated as closely as possible. 

As Microsoft shifts its philosophy to this new approach, we are asking the broader security community to embrace the purpose of this shift, which is ultimately about minimizing customer risk-not amplifying it. This distinction is critical. We recognize it's possible that very limited attacks may be happening without our knowledge. However, we fundamentally believe (and our experience over the last 10 years has shown) that once vulnerability details are released publicly, the probability of exploitation rises significantly. Without coordination in place to provide a security update or tested workarounds, risk to customers is greatly amplified. 

It is evident from listening to those on both extremes of the disclosure argument that there is one thing that we are all trying to do: protect customers. We've been working with the security community closely for years to coordinate our actions for the benefit of customers. Coordinated vulnerability disclosure will help keep users safe.

For further perspective on CVD and how we see it working, please see Katie Moussouris' Ecostrat blog post at http://blogs.technet.com/b/ecostrat/archive/2010/07/22/coordinated-vulnerability-disclosure-bringing-balance-to-the-force.aspx.

Thank you,

Matt Thomlinson
General Manager, Trustworthy Computing Security

Hi,

During the July 2010 webcast, we fielded questions varying from the re-release of MS10-024 to answers for the error messages received during the application of MS10-041 and more.   Click  here to review the full Q&A page so you can see all of the answers that were provided for these and the other great questions from the July webcast.

Also, attached here is the link to the Q&A index page for your review -  in case you wanted to view any of the past 12 webcast Q&A's.

 As always, customers experiencing issues installing any of the updates this month should contact our Customer Service and Support group:

• Customers in the U.S. and Canada can receive technical support from Microsoft Product Support Services at 1-866-PCSAFETY. There is no charge for support calls that are associated with security updates.
• International customers can receive support from their local Microsoft subsidiaries. There is no charge for support that is associated with security updates. For more information about how to contact Microsoft for support issues, visit the International Support Web site.

Thanks!

Jerry Bryant

Group Manager, Response Communications

 Click here to register for next month's webcast.

We've just updated Microsoft Security Advisory 2286198 to let customers know that we now have an automated "Fix It" available to implement the workaround we first outlined in our original posting on Friday, July 16, 2010. More information is available in the KB article 2286198, but in summary running the "Fix It" can help prevent attacks attempting to exploit this vulnerability. This workaround will disable some icons from being displayed so we recommend administrators test this before deploying it widely.

We've also updated the advisory with new information regarding possible attack vectors. Finally, we have included a new workaround that customers can implement to help protect their environments: blocking the download of LNK and PIF files (note that these files can be transferred over WebDav, so be sure to account for this protocol if you implement this workaround).

As always, we encourage customers to review this new information and to evaluate it for their environment while our teams continue their work to develop a security update that addresses this vulnerability.

As always, we'll update the security advisory and this blog with new information as it becomes available.

Thanks,

Christopher Budd

Sr. Security Manager, Response Communications at Microsoft

Follow us on Twitter: @MSFTSecResponse

Hi everyone,

We have released Security Advisory 2286198, which addresses a publicly reported vulnerability in Windows Shell. Microsoft has found that this vulnerability is most likely to be exploited through removable drives. Currently, we have seen only limited, targeted attacks on this vulnerability.

In the wild, this vulnerability has been found operating in conjunction with the Stuxnet malware, a threat family already known to the Microsoft Malware Protection Center. The MMPC has a blog post with more technical discussion of Stuxnet.

We recommend that customers follow the guidance provided in the Security Advisory, making note of mitigations and tested workarounds. We will continue to investigate the vulnerability and, upon completion of that investigation, we will take appropriate action to protect our customers.

Customers should be aware that signatures in up-to-date versions of Microsoft Security Essentials, Microsoft Forefront Client Security, Windows Live OneCare, the Forefront Threat Management Gateway, and the Windows Live Safety Platform protect customers against the Stuxnet malware.

We are also actively working with members of our Microsoft Active Protections Program (MAPP) to provide information that they can use to provide broader protections to customers. Anyone believed to have been affected by this issue can visit: http://support.microsoft.com and should contact the national law enforcement agency in their country. 

We will continue to share updates on this blog and through our Twitter feed (@msftsecresponse).

Thanks,

Dave Forstrom
Director of Marketing Communications, Integrated Communications & Response

Hi everyone. As part of our usual monthly update cycle, today Microsoft is releasing four security bulletins to address five vulnerabilities in Windows and Microsoft Office.

MS10-042 resolves a publicly disclosed and actively exploited vulnerability discussed in Security Advisory 2219475. The update addresses an issue in the Windows Help and Support Center feature included in Windows XP and Windows Server 2003. Even though this issue affects Server 2003, we have not found an attack vector on that platform so the severity rating is Low. Windows XP customers should install this update as soon as possible.

MS10-043 resolves a publicly disclosed vulnerability in the Canonical Display Driver (cdd.dll). Although it is possible that the vulnerability could allow code execution, successful code execution is unlikely due to memory randomization. In most scenarios, it is much more likely that an attacker who successfully exploited this vulnerability could cause a Denial of Service (DoS). Note that this bulletin affects only 64-bit versions of Windows 7 and Windows Server 2008 R2 with Windows Aero enabled. Aero is not installed by default on Server 2008 R2. We are not aware of any active attacks against this issue.

MS10-044 resolves two privately reported vulnerabilities in Microsoft Office Access ActiveX Controls. This issue could allow remote code execution if a customer with Access installed opened a specially crafted Office file, or viewed a Web page that instantiated Access ActiveX controls. This security update is rated Critical for supported editions of Microsoft Office Access 2003 and Microsoft Office Access 2007.

MS10-045 This security update resolves another privately reported vulnerability that could allow remote code execution if a customer opened an attachment in a specially crafted e-mail message using an affected version of Outlook -- Microsoft Outlook 2002, Microsoft Office Outlook 2003, or Microsoft Office Outlook 2007.

The following video provides an overview of these four bulletins:

Other listening and viewing options:

• Windows Media Video (WMV)
• Windows Media Audio (WMA)
• iPod Video (MP4)
• MP3 Audio
• High Quality WMV (2.5 Mbps)
• Zune Video (WMV)

Both Windows vulnerabilities and one Office vulnerability have Critical severity ratings, while the second Office vulnerability carries an Important severity rating.

As always, Microsoft recommends that customers test and deploy all security updates as soon as possible. We recommend that deployment priority be given to MS10-042 and MS10-045.

For a more in-depth look at these issues, our Security Research & Defense (SRD) team has taken a closer look at both these bulletins on its blog.

We also include one bulletin re-release, MS10-024, in this cycle. The re-release will address the issue previously noted in KB976323, in which the installation of the bulletin reset user-configured settings for SMTP servers on Windows Server 2008-based systems with Internet Information Services (IIS) installed. Users who have previously installed MS01-024 will not be offered the re-released update.

Today also marks the end of support for Windows XP Service Pack 2. Customers who have not migrated from this version are encouraged to upgrade immediately, either to Service Pack 3 or to Windows 7. In addition, after today's bulletin release, we will no longer provide support for all Windows 2000 products as we have reached the end of extended support.

More information about the security updates can be found on the Microsoft Security Bulletin summary webpage.  Our Exploitability Index provides additional information to help customers prioritize deployment of the monthly security bulletins.

Please join the monthly technical webcast to learn more about the May 2010 security bulletin release. The webcast is scheduled for Wednesday, July 14, 2010 at 11:00 a.m. PDT (UTC -7). Registration is available here.

Reminder: You can follow the team for late breaking news and updates on the threat landscape here: @MSFTSecResponse.

Thanks!

Jerry Bryant
Group Manager, Response Communications

Hi everyone. Today we're releasing our advance notification for the July security bulletin release, which is scheduled for Tuesday, July 13. This month's release includes four bulletins addressing five vulnerabilities.

• Two bulletins, both with a severity rating of Critical, affect Windows.
• Two of the bulletins affect Microsoft Office; of those, one carries a Critical severity rating and one is rated Important.

As always, we recommend that customers review the ANS summary page for more information and prepare for the testing and deployment of these bulletins as soon as possible.

We will close out two Security Advisories this month.

• We are closing Security Advisory 2028859 (Vulnerability in Canonical Display Driver Could Allow Remote Code Execution) in the July bulletins.
• We are also closing Security Advisory 2219475 (Vulnerability in Windows Help and Support Center Could Allow Remote Code Execution) with a comprehensive update that addresses the issue currently under attack.

Please join Adrian Stone and me for a public webcast on Wednesday. We'll go into detail about the bulletins and answer questions live on the air. Register at the link below:

Date: Wednesday, July 14
Time: 11:00 a.m. PDT (UTC -7)
Registration: https://msevents.microsoft.com/CUI/WebCastEventDetails.aspx?EventID=1032454299

Also, July marks the end of Microsoft support for the Windows 2000 and Windows XP SP2 platforms. Customers should actively seek out either a supported operating system or the latest service pack in order to keep receiving necessary security updates.

Thanks,

Jerry Bryant
Group Manager, Response Communications

Follow us on Twitter: @MSFTSecResponse

Updated July 9, 2010 to correct transposition concerning number of critical bulletins for Windows (accurately, two) and MS Office (accurately, one).

Hosts:                                   Adrian Stone, Senior Security Program Manager Lead

                                             Jerry Bryant, Group Manager, Response Communications

Website:                              TechNet/security

Chat Topic:                          June 2010 Security Bulletin Release

Date:                                    Tuesday, June 8, 2010

Q: The .NET updates are only a security update correct? Not a service pack or rollup, right?

A: The June Security Bulletin release had one security bulletin, MS10-041, for the .NET Framework and another set of updates corresponding to Microsoft Security Advisory 973811. The update corresponding to Microsoft Security Advisory 973811 carries the extended protection security feature, so that is not a security update in the traditional sense. But there was no service pack or rollup in the June release.

Q: Will Microsoft provide updates for Windows 2000 next month? Do you recommend we upgrade to a newer version of Windows?

A: We remind all Windows 2000 and Windows XP SP2 customers that all support for these platforms will end after July 13, 2010. Customers should upgrade to either a supported operating system or the latest service pack in order to keep receiving necessary security updates. We will release appropriate bulletins for Windows 2000 and Windows XP SP2 next month.

Q:  Why does the update required in KB979909 prompt for an interaction? This causes it to fail installation on Windows Update.

A: Security updates deployed via Windows Update generally do not prompt for user input; however some updates may display an End User License Agreement (EULA) which needs to be accepted before the update is installed. If the update KB979909 is installed in the same transaction as another update which shows a EULA then it may appear like the prompt is coming from the update KB979909. We are not aware of any specific issues at this times that may cause KB979909 to display a user prompt, but if you are encountering this issue please contact 1-866-PC-SAFETY and our support engineers should be able to assist.

Q: Why was the Cumulative IE patch MS10-018 automatically declined by Windows Server Update Services (WSUS) when MS10-035 was just released?  Also, MS10-018 can no longer be approved either.

A: This month’s IE update did initially experience some detection issues in the update, but this has been corrected. As the IE updates are Cumulative in nature, the updates provided in MS10-018 are included in MS10-035. If you install the latest IE update, it will include the previous fixes.

Q: For clarity, when will these updates be released for download by System Center Configuration Manager (SCCM)?

A:  Most of the updates are available via SCCM. Please see the bulletin for specifics.

Q: In testing these updates  on release day we had multiple Windows XP systems that were idle (no applications in use), I was surprised to find that it took two or even three cycles of patches and reboots to get all the updates installed. In other words, rather than one reboot at the end, there were some updates then reboot, more updates then reboot. On one machine, yet more updates and another reboot.  Can you explain why that is necessary?  Microsoft updates are usually sequenced better than this, so that only one reboot is needed.

A: Without specific parsing of logfiles, it's difficult to diagnose multiple reboot scenarios but I would guess that it's possible you had earlier updates that had not yet been applied to this machine, or you had not yet rebooted from a prior update installation. Windows Update requires that if you have a pending reboot that the reboot must be completed before it can install newer updates. That may be the reason for the behavior you observed.

Q: In reviewing our (WSUS) server this morning after synchronization overnight, MS10-033 was not yet available. Has this update been made available for WSUS?

A: There are multiple KB's associated with MS10-033.  Please refresh your WSUS scan cab file and contact Customer Service if you still experience this issue.

Q: Concerning MS10-041, are all of the updates required to be installed? For example, we have deployed .NET 3.5 SP1 as a package that also updated some earlier versions of .NET. Does the same apply here? Does the update for .NET 3.5 SP1 also patch the earlier versions of .NET?

A: You can have more than one version of the .NET Framework installed side-by-side. Therefore, yes, you need to install all updates that pertain to versions of the .NET Framework you have installed. Technologies like Windows Update (WU), Microsoft Update MU) and WSUS will detect automatically which updates are applicable to your system. For more information, please see the General FAQ section in the MS10-041 bulletin, specifically the question: "How do I determine which version of the Microsoft .NET Framework is installed?"

Q: When Windows XP SP2 falls out of support, does that mean Windows XP x64 is totally out of support?  There isn’t a Service Pack 3 (SP3) for Windows XP x64.

A: Windows XP x64 released to manufacturing (RTM) is out of support. We recommend upgrading to Windows XP x64 SP2.  See http://support.microsoft.com/lifecycle/ for a full listing of supported platforms.

Q: Does installation of MS10-039 in a multi-server Microsoft Office SharePoint Server 2007 (MOSS) environment require manual, ordered installation and running of the wizard, similar to a MOSS service pack deployment?

A: Yes, the installation of MS10-039 on a multi-server MOSS environment does require manual install. For best results you should also do an ordered installation.

Q: For MS10-033, can email firewall vendors scan attachments for this vulnerability?

A:  In the case of malicious media content attached to email, yes they can, although there are attack vectors affected by this vulnerability that can’t be scanned by email scanners -- for instance, a malicious website can host specially crafted media content.  In this scenario, an email firewall will not mitigate against this issue.

Q: MS10-039 does not appear in Windows or Microsoft Update.  How is this update applied?

A: Security updates are available from the Microsoft Download Center. You can find them most easily by doing a keyword search for "security update."  In addition, security updates can be downloaded from the Microsoft Update Catalog. The Microsoft Update Catalog provides a searchable catalog of content made available through Windows Update and Microsoft Update, including security updates, drivers and service packs. By searching using the security bulletin number (for instance, “MS10-039"), you can add all of the applicable updates to your basket (including different languages for an update), and download to the folder of your choosing. For more information about the Microsoft Update Catalog, see the Microsoft Update Catalog FAQ.

Q: Not sure if it was addressed, but has MS10-020 and the issues saving files to network shares been resolved?

A: You can review KB980232 to see the latest information about this issue.  All known issues and their resolutions will be listed there.

Q:  The bulletin for MS10-039 says an "attacker could gain the same user rights on the SharePoint site as the targeted user.” If targeted user is a Domain Admin, would attacker have Domain Admin rights on all domain members?

A: No. For CVE-2010-0817 the targeted user can only gain rights in SharePoint and not on the domain.  When an attacker initiates this attack and they convince the targeted user to click the Cross-Site-Scripting (XSS) link, the attacker is essentially tricking the targeted user to run commands sent by the attacker against the SharePoint server.

Q: Do we have any detection logic in this month’s Kernel update so that it doesn’t create any big impact, such as the blue screen of death (BSOD) issue of February’s release?

A: There are no updates this month that require additional detection logic.  We have no reports of known issues at this time that would cause us to use this type of detection logic.

Q: Are known issues tracked on the knowledge base (KB) article associated with each of the updates? How often is that updated?

A:  All known issues are tracked through the bulletin’s KB article. These are added as issues are identified.

Q: Regarding MS10-039 for Office SharePoint, does the user need to successfully log into the site to submit the request?

A: For both the CVE-2010-1257 Information Disclosure issue and the CVE-2010-1264 denial of service (DoS) issue, in the SharePoint bulletin MS10-039, authentication is required. However, for CVE-2010-0817 -- the help .aspx issue -- no authentication to the SharePoint server is required.

Q: I don't mean to sound stupid but what is meant by applying a shim? And what is a shim?

A: With the Shim infrastructure, which we also call the Microsoft Windows Application Compatibility Infrastructure, you can target a specific application fix but only for a particular application (and typically, for particular versions of that application), with these fixes housed outside the core Windows functions and maintained separately.  To get a complete understanding of shim technology, please see http://technet.microsoft.com/en-us/library/dd837644(WS.10).aspx.

Hello -

We have released Security Advisory 2219475, addressing the vulnerability in the Windows Help and Support Center function in Windows XP and Windows Server 2003. We are not aware of any active attacks at this time. Customers running Windows Vista, Windows 7, Windows Server 2008 and Windows Server 2008 R2 are not vulnerable to this issue or at risk of attack.

We recommend that customers follow the guidance in the Advisory, noting the mitigations and workarounds.  The Security Research and Defense team has a blog with more technical details about this issue.  

As always, Microsoft strives to work with security researchers to address vulnerabilities in our software. This helps ensure that customers receive comprehensive, high-quality updates before cyber criminals learn of - and work to exploit - a vulnerability. Responsible disclosure protects the computer ecosystem and individual computer users from harm.

We are actively working with partners in our Microsoft Active Protections Program (MAPP) to provide information that they can use to provide broader protections to customers. Anyone believed to have been affected by this issue can visit: http://support.microsoft.com and should contact the national law enforcement agency in their country. 

We will continue to share updates on this blog and through our Twitter feed (@msftsecresponse).

Thanks,

Jerry Bryant
Group Manager, Response Communications

Hello,

We are aware of a publicly disclosed vulnerability affecting Windows XP and Windows Server 2003. We are not aware of any current exploitation of this issue and customers running Windows Vista, Windows 7, Windows Server 2008, and Windows Server 2008 R2, are not vulnerable to this issue, or at risk of attack.

This issue was reported to us on June 5th, 2010 by a Google security researcher and then made public less than four days later, on June 9th, 2010.  Public disclosure of the details of this vulnerability and how to exploit it, without giving us time to resolve the issue for our potentially affected customers, makes broad attacks more likely and puts customers at risk

One of the main reasons we and many others across the industry advocate for responsible disclosure is that the software vendor who wrote the code is in the best position to fully understand the root cause. While this was a good find by the Google researcher, it turns out that the analysis is incomplete and the actual workaround Google suggested is easily circumvented. In some cases, more time is required for a comprehensive update that cannot be bypassed, and does not cause quality problems. 

We recognize that researchers across the entire industry are a vital part of identifying issues and continually improving security, and we continue to ask researchers to work with us through responsible disclosure to help minimize the risk to customers while improving security.

We have initiated our emergency response process and will continue to monitor the threat landscape for any signs of attack against this issue. Our Microsoft Active Protections Program (MAPP) partners have detailed information about this vulnerability and are developing protections where possible.

Update: customers can follow guidance in Security Advisory 2219475 to protect against this issue.

Update 6/25/2010:
The security researcher who disclosed this vulnerability has expressed concerns regarding the inclusion of his employer’s name in relation to this vulnerability.  While there continues to be a difference of opinion, we have included both this researcher’s view and our view in this blog post. His point of view is that he reported the vulnerability not as an employee, but as an individual action by him as an independent researcher.

At Microsoft we do not believe that its feasible to disassociate the two.  We believe the actions of employees, when related to the work they are doing at a technology company, should reflect the policies of their employer. 

Despite these differences of opinion, we continue an open dialog with this researcher and ask the security researcher community to continue working with us to help protect customers.