In October 2009, we released a tool on this blog called EMET that provides users with the ability to deploy security mitigation technologies to arbitrary applications. Doing so helps to prevent vulnerabilities in those applications (especially line of business and 3rd party apps) from successfully being exploited. It also responds to requests from customers to help manage risk in older, legacy products while they are in the process of transitioning over to modern, more secure products. Beyond that it makes it easy for customers to try mitigations against any software and provide feedback on their experience to the vendor.
EMET sparked customer interest and based on the feedback that we received, we decided to release version 2 that includes more mitigations, a better interface, and a more robust infrastructure compared to the earlier version of EMET.
Our aim with this version is to provide an innovative solution that helps customers manage risk and minimize disruption in their environment. This is reflected in our goals for the release:
These new goals increase the scope of EMET significantly from version 1. As a result, the old definition of EMET (Enhanced Mitigation Evaluation Toolkit) is no longer a good fit. With version 2, we are changing the EMET acronym to stand for Enhanced Mitigation Experience Toolkit to reflect this.
While EMET can be used by anybody, it is primarily targeted at protecting applications on machines that are at high risk for attack. Good examples include line of business applications on backend servers and browsers on the desktops of corporate executives. These are scenarios where an application compromise could be particularly damaging.
As with most software, deploying this tool will likely involve an individual, such as an IT professional, testing to ensure that EMET works smoothly with applications where the mitigations are desired (like line of business applications and 3rd party products). Once in place, EMET will be transparent to the end user.
That said of course EMET is also ideal for any security savvy user wishing to harden the apps they use against possible exploitation. Developers and security professionals can also use it as a convenient way to try out security mitigations.
During the Aurora outbreak back in January 2010, Data Execution Prevention and Address Space Layout Randomization (two types of mitigation technologies) played an important in blocking known attacks. You can find more information on these SRD blog posts IE Vulnerability Risk Accessment and DEP and the New IE Vulnerability
The new version of EMET will include a total of six mitigations. Four of them are from the original EMET, while Export Address Table Access Filtering and Mandatory Address Space Layout Randomization are new for version 2. Here are some more details on the mitigations:
DEP has been available since Windows XP. However, current configuration options don’t allow applications to be opted in on an individual basis unless they are compiled with a special flag. EMET allows applications compiled without that flag to also be opted. For more information on what DEP is and how it works, take a look at Part 1 and Part 2 of our two-part SRD blog post on it.
This protects against currently the most common technique for exploiting stack overflows in Windows. This mitigation has shipped with Windows since Windows Vista SP1. Recently with Windows 7, the ability to turn it on and off per process was added. With EMET, we provide the Windows 7 capabilities on any platform back though Windows XP. For more information, take a look at the SEHOP Overview and Window 7 SEHOP Changes blog posts.
When an exploit runs, it often cannot be sure of the address where its shellcode resides and must make a case when taking control of the instruction pointer. To increase the odds of success, most exploits now use heapspray techniques to place copies of their shellcode at as many memory locations as possible. This mitigation blocks the use of addresses most common in today’s exploits.
This is similar technology to the heap spray allocation, but designed to prevent potential null dereference issues in usermode. Currently there are no known ways to exploit them and thus this is a defense in depth mitigation technology.
This mitigation is designed to break nearly all shell code in use today. Before a piece of shellcode can do anything useful, it generally has to locate windows APIs first. This mitigation blocks a common current technique shellcode uses to do this.
ASLR randomizes the addresses where modules are loaded to help prevent an attacker from leveraging data at predictable locations. The problem with this is that all modules have to use a compile time flag to opt into this. With EMET, we force modules to be loaded at randomized addresses for a target process regardless of the flags it was compiled with.
Please stay tuned for the actual binaries which will get released in the upcoming weeks. Our blog will be updated with the latest news and download links as soon as that happens.
We’ve put together a Bluehat video to walk through the tool and explain many of its advantages and capabilities. The video can be found on the BlueHat site linked here. We hope you enjoy it.
Thanks to Matt Miller and Ken Johnson for their work on EMET.
- Andrew Roths and Fermin J. Serna, MSRC Engineering
Today we released MS10-042 to address CVE-2010-1885, a Critical severity security issue in the Help and Support Center. Windows XP is affected and we have seen limited attacks, so we encourage everyone to depoy the update right away. Windows Server 2003 also contains the vulnerable code; however, we have not identified a way for an attacker to exploit it. Uplevel versions of Windows do not contain Help and Support Center and as such are not vulnerable.
Background on Help and Support Center Vulnerabilities
Help and Support Center vulnerabilities, CVE-2010-1885 included, generally involve local content enabling injection of script into the Help and Support Center environment. In the case of CVE-2010-1885, the local content targeted was a file, “sysinfomain.htm.” This content references a helper library, “commonFunc.js,” which contains DOM-based XSS. Specifically, commonFunc.js enables an untrusted querystring parameter to be injected onto the page. This in turn enables the execution of attacker-controlled commands.
By design, Help and Support Center allows trusted Help content on Windows XP and Windows Server 2003 to execute privileged commands enabling Help related functionality. Given the presence of an injection issue, the powerful Help and Support Center environment can enable execution of arbitrary code.
A Note about Potential Mitigations
The attack scenario for this vulnerability involves navigation to an hcp:// protocol URL. Browsers including Internet Explorer 8 have recently begun to implement warning prompts before navigation to less-common URL schemes.
One example proof-of-concept exploit for CVE-2010-1885 demonstrated the use of Windows Media Player 9 to navigate to the hcp:// protocol and avoid the IE8 prompt. More recent versions of Windows Media Player prompt before loading arbitrary HTML content and thus do not enable this attack scenario.
Nevertheless, we view the newly introduced protocol prompting behavior in browsers to be at best defense-in-depth. We do not believe that these prompts provide sufficient mitigation for the identified Help and Support Center vulnerability in all cases. Thus they are not called out as mitigations in MS10-042.
Ruling out URL Decoding as the Primary Issue
Our analysis of the vulnerability is that it is due to a bug in the URL validation performed by Help Center, not due to a bug in URL decoding functionality within Help and Support Center.
As identified in the original vulnerability report, a malformed URL can result in failure of the Help and Support Center URL decoding routine. That in itself is expected, however Help and Support Center subsequently ignores the associated failure condition and thus the resulting decoded URL is left in an arguably invalid state. The report also made the assertion that the URL decoding could be held responsible for the security of the URL validation in Help and Support Center as a whole. However, it is possible to construct a validly-encoded URL that would decode to the same in-memory representation as the invalidly-decoded proof-of-concept URL. So, fixing the handling of URL decoding failure would not address the underlying vulnerability.
Digging Deeper
In the scenario identified as part of the vulnerability report, Help and Support Center validates URLs using a Jet database containing an index of locally installed Help content. This database is located in %windir%\PCHealth\Database\HCdata.EDB. A query is issued against the database looking for a particular piece of help content. If this content is indexed in the database, the local file is then authorized to load within Help and Support Center. In the case of the reported vulnerability, it was possible for an attacker to bypass validation and trigger navigation to sysinfomain.htm with a maliciously constructed URL.
CVE-2010-1885 leverages the fact that the query against the Jet database is not a true string comparison. In reality, it’s a comparison of keys generated by the LCMapString API. So the attacker-supplied input maps down to a string that improperly matches content contained within the Jet database. When the query is issued against the database, the database code identifies the malformed file name to exist (several times!) even though it is not present.
Minimal Risk on Windows Server 2003
As it turns out, the HCdata.EDB database file is significantly different between Windows XP and Windows Server 2003. On Windows Server 2003 the database file does not contain the base URLs necessary to match database queries for HCP:// protocol content. Because the vulnerable Help and Support Center code exists on Windows Server 2003, we were able swap in the EDB file from Windows XP and observe the exploit function. However, we were unable to construct an attack that would work with the standard Windows Server 2003 EDB file. Nevertheless, we are addressing the issue as a low severity vulnerability on Windows Server 2003.
- MSRC Engineering Team Bloggers
Today we released the fix for CVE-2010-0266, an Important severity vulnerability in Microsoft Office Outlook. Yorick Koster working with the SSD/SecuriTeam Secure Disclosure program reported this issue.
What’s the risk?
This vulnerability enables an attacker to spoof a dangerous e-mail attachment to appear legitimate / benign. If a victim user were to open the attachment, code from a remote UNC path could execute without prior warning.
UNC paths are commonly known to reference SMB resources. However, edge firewalls typically block SMB, so SMB is less likely to be used for Internet-based attacks. That said, UNC paths can also access resources via HTTP. On Windows XP and more recent platforms, the WebDAV mini-redirector (a.k.a. the WebClient service) enables web content to be accessed via UNC paths. This is more likely to pass through firewalls as WebDAV is an extension of HTTP and commonly traverses port 80 like web browser traffic.
To see the WebDAV mini-redirector in action, try the following:
How can I protect myself?
First, we recommend applying the update as soon as possible. If you are not able to apply the update there is a workaround that can help protect your environment from WebDAV-based attacks. While this won’t prevent all attacks it will block the most likely vector for Internet-based attacks.
Workaround - Disable the WebClient Service
Disabling the WebClient service helps protect affected systems from attempts to exploit this vulnerability by blocking the most likely remote attack vector through the Web Distributed Authoring and Versioning (WebDAV) client service. After applying this workaround it will still be possible for remote attackers who successfully exploit this vulnerability to cause Microsoft Office Outlook to run programs located on the targeted user's computer or the Local Area Network (LAN), but users will be prompted for confirmation before opening arbitrary programs from the Internet.
To disable the WebClient Service, follow these steps:
Impact of workaround
When the Web Client service is disabled, Web Distributed Authoring and Versioning (WebDAV) requests are not transmitted. If the Web Client service is disabled, any services that explicitly depend on the Web Client service will not start, and an error message will be logged in the System log. For example, WebDAV shares will be inaccessible from the client computer.
How to undo the workaround.
To enable the WebClient Service, follow these steps:
Thanks to Kevin Brown, Naveen Palavalli, and Andrew Roths for contributing to this blog post.
- David Ross, MSRC Engineering
Yesterday evening, one of Google’s security researchers publicly released vulnerability details and a working exploit for an unpatched vulnerability in Windows XP and Windows Server 2003. This afternoon, we’ve released security advisory 2219475 with official guidance. We’d like to use this blog entry to share more details about the issue and ways you can protect yourself.
The vulnerability
Firstly, Windows 7, Windows Server 2008, Windows Vista, and Windows 2000 are not impacted by this vulnerability. Those platforms do not include the Help and Support Center application, which contains this vulnerability.
However, Windows XP and Windows Server 2003 do include the Help and Support Center application (helpctr.exe). On those platforms, clicking on an hcp:// link launches helpctr.exe via a registered protocol handler. Launching the Help and Support Center via an hcp:// link is normally safe and is a supported way to launch help content. This is due in part to an “allow list” of safe pages that Help and Support Center checks before navigating to a passed-in page. The Google security researcher found a help page with a cross-site scripting vulnerability and also a mechanism by which to abuse the allow list functionality to access that page with an exploit querystring. Clicking on a malicious hcp:// link leverages the XSS vulnerability to circumvent helpctr.exe’s safety controls and ultimately run an arbitrary exe installed on the machine.
It’s also important to note that while Windows Server 2003 does include helpctr.exe and the hcp:// protocol handler, the specific exploit posted by the Google security researcher does not result in code execution on Windows Server 2003. We are still investigating this and have not yet ruled out the possibility of code execution.
How to Protect Yourself
The full-disclosure advisory included a hotfix tool built by the Google security researcher. Unfortunately it is ineffective at preventing the vulnerable code from being reached and can be easily bypassed. We recommend not counting on the Google hotfix tool for protection from the issue.
The best workaround is to unregister the hcp:// protocol handler. Doing so will prevent the chain-of-events that leads to the code execution. Here is a registry script to disable the protocol handler:
Windows Registry Editor Version 5.00 [-HKEY_CLASSES_ROOT\HCP]
Pasting this into a .reg file and opening with regedt32 will disable the hcp:// protocol handler. You can find the interactive steps and the rollback instructions in the security advisory.
The Help and Support Center does use hcp:// links internally so temporarily disabling the protocol handler may impact Help and Support Center’s ability to, for example, initiate Remote Assistance requests.
We are actively working on a security update to comprehensively address the issue. We are also working on a Microsoft FixIt to automate disabling the hcp:// protocol handler.
Thanks to the MSRC Engineering team for the quick investigation of this issue: David Ross, Chengyun Chu, Bruce Dang, Andrew Roths, and Jonathan Ness.
*Posting is provided "AS IS" with no warranties, and confers no rights.*
Today we released ten security bulletins. Three have a maximum severity rating of Critical and seven have a maximum severity rating of Important. We hope that the table below helps you prioritize the deployment of the updates appropriately for your environment.
Bulletin
Most likely attack vector
Max Bulletin Severity
Max Exploit-ability Index Rating
Likely first 30 days impact
Platform mitigations and key notes
MS10-035
(IE)
Victim browses to a malicious webpage.
Critical
1
Proof-of-concept has been presented publicly for Information Disclosure issue.
Likely to also see exploit released for one or more of these memory corruption vulnerabilities.
IE users on later platforms at reduced risk due to Protected Mode mitigating the information disclosure issue. IE8 users on Windows Vista and Windows 7 at reduced risk due to presence of DEP and ASLR.
Please see this SRD blog post for more information
MS10-033
(quartz.dll)
Victim browses to a malicious webpage or opens a malicious AVI movie with Media Player.
Likely to see an exploit released able to exploit the vulnerability in MJPEG parsing.
MS10-034
(killbits)
n/a
May see an exploit released able to exploit one or both of the Microsoft ActiveX controls.
CVE-2010-0252: Victim must have Office XP’s Data Analyzer (MSDA) package installed to be vulnerable.
CVE-2010-0811: User interaction required
MS10-032
(kernel drivers)
Attacker already running code with low privileges on a vulnerable machine runs a malicious EXE to elevate to a higher privilege level.
Important
Likely to see an exploit released able to elevate from a low privileged user on the box to a higher privilege.
Please see this SRD blog post for more information about exploitability
MS10-038
(Excel)
Victim opens a malicious XLS file that exploits a vulnerability to run arbitrary code.
Exploit likely to be developed for one of more of these XLS parsing vulnerabilities in the next 30 days.
MS10-036
(Office ActiveX)
Victim opens a malicious Office document that instantiates an ActiveX control to result in code execution.
Likely to see malicious Office documents that exploit this within the next 30 days.
MS10-039
(SharePoint)
Victim clicks an attacker-sent link to a Sharepoint server on which they have administrative rights. Attacker-supplied link causes them to take an automatic action on the Sharepoint Server.
Proof-of-concept already public for this issue. However, we have not heard of real-world attacks from either customers or partners.
MS10-040
(IIS)
Attacker connects remotely over HTTP to IIS server that has installed the (optional) Channel Binding Update and has enabled (off-by-default) Windows Authentication.
2
Less likely to see exploits developed resulting in successful code execution in next 30 days.
MS10-037
(OpenType)
Local user running at low privileges on a vulnerable machine runs a malicious EXE to elevate to a higher privilege level.
Less likely to see exploits developed resulting in successful code execution in next 30 days
MS10-041
(.NET)
Custom .NET applications that rely on XML signature protection as tamper protection could be tampered with in an undetected manner.
3
Unlikely to see exploit developed in the next 30 days.
No Microsoft .NET applications are vulnerable to this issue. Usage of the specific API thought to be low in real-world.
Special thanks to all of MSRC Engineering for their work on these cases.
- Jonathan Ness, MSRC Engineering
Today we released a security update rated Important for CVE-2010-1255 in MS10-032. This vulnerability affects the win32k.sys driver. This blog post provides more information about this vulnerability that can help with prioritizing the deployment of updates this month.
A local attacker could write a custom user-mode attack application that passes a bad buffer to win32k.sys’s GetGlyphOutline while retrieving font information. This could be an attempt to cause memory corruption with the end goal of running code in ring 0 -- a classic local Elevation-of-Privilege vulnerability.
If a regular, known-good application failed to properly request the length of the buffer when calling this API, that application might expose a different code execution attack vector to this vulnerability. Fortunately, default installations of Windows are not at risk because the API is properly used in Microsoft applications. If a third-party application inadvertently used this function incorrectly, this security update will protect any attack vector exposed by that application as well. In that light, the deployment priority of this update may need to be adjusted accordingly.
How difficult is this to exploit?
Due to a validation statement in the write loop, the attacker cannot write data of arbitrary length beyond the allocated buffer; the overwrite length is approximately 0x10 bytes. Getting all of the data in the right place at the right time to gain code execution can be quite unreliable and as a result we gave it an Exploitability Index rating of 2. We do not expect to see reliable exploit code within the next 30 days.
We would like to thank Colin McCambridge for his work on this case.
- Bruce Dang, Brian Cavenah, and Jonathan Ness from MSRC Engineering
Today we released MS10-035, a security update with an Important severity update, addressing CVE-2010-0255. We’d like to talk briefly about that specific vulnerability and how we’ve addressed it.
Background information
This issue primarily impacts Internet Explorer running on Windows XP. Attacks against Internet Explorer running on Windows Vista and newer platforms are mitigated by Internet Explorer Protected Mode. This issue involves an attacker navigating directly to the user’s cache index file, index.dat, via a UNC path. Script planted in index.dat could in some cases execute in a security context enabling read access to other content on the local filesystem. Internet Explorer Protected Mode is a powerful mitigation because it disables the ability to access resources on the local filesystem via UNC paths, by default.
How would someone take advantage of this vulnerability?
An attack would involve malicious web content navigating a victim’s browser to a UNC path referencing index.dat on the local filesystem. Script planted within index.dat would then be able to read data from other local files on the machine. The attacker could then access files in predictable paths assuming the files were not locked for read or otherwise inaccessible. (e.g., restricted for read by the current user due to ACLs.)
Mitigations
All mitigations discussed in the following blog post would apply to CVE-2010-0255 as well:MS09-019 (CVE-2009-1140): Benefits of IE Protected Mode, Additional Network Protocol Lockdown workaround
Specifically, besides Internet Explorer Protected Mode, Network Protocol Lockdown can be used to prevent exploitation of this issue.
The code change being made to address CVE-2010-0255 is also present on Windows Vista and newer platforms simply because users or administrators may have manually disabled Internet Explorer Protected Mode. Future attack scenarios may result in further code changes, though we anticipate that Internet Explorer Protected Mode will continue to provide protection against this overall threat class.
Thanks to Chengyun Chu for his contribution to this blog post.
Today we released MS10-041 addressing an issue in the implementation of the XML signature functionality in the .NET Framework with an Important severity rating. We’d like to shed more light on that case here.
Am I at risk?
No Microsoft products are subject to this vulnerability. However, .NET applications that use the System.Security.Cryptography.Xml.SignedXml.CheckSignature(KeyedHashAlgorithm macAlg) method are susceptible. Note that only the CheckSignature() method that takes a KeyedHashAlgorithm parameter is affected – the other CheckSignature() methods are not.
Anyone running applications that call this method should install this update as soon as possible. The update protects against the vulnerability without the need to recompile these applications.
If you allow updates to install automatically, there’s nothing else you have to do. Once the update has been installed, your applications will be safe from this vulnerability. In addition, after extensive evaluation we’ve assigned this vulnerability an overall Exploitability Index rating of 3, meaning that we believe that functioning exploit code is unlikely in the near future.
What could an attacker do?
As the bulletin explains, this vulnerability could make it possible for an attacker to modify XML signature protected data without being detected. The impact of the tampering depends on how the affected data is intended to be used by the specific application, but is unlikely to result in arbitrary code execution.
One of the features of an XML signature is the ability to embed a value, called the HMACOutputLength, in the signature that tells the receiver how many bits of the signature to examine. However, the specification did not require that implementations of the specification enforce a minimum value for this field.
In the .NET implementation, as well as other implementations by other vendors, no minimum HMACOutputLength value was enforced, so a man-in-the-middle attacker could set this value to 0 and then tamper with the contents of the XML without detection.
The updated specification now says that implementations must validate that HMACOutputLength is >= MAX(80, HalfOfTheBitsTheSignatureMethodGenerates).
XML signatures are defined by the W3C in this document: http://www.w3.org/TR/xmldsig-core/
How to determine if you have any affected applications on your computer
The .NET Framework SDK comes with a disassembly tool which can extract the IL code from a .NET binary. The following PowerShell script calls this tool for every .EXE and .DLL file under the folder you execute the script in, and examines the output of the tool to tell you if any of the binaries call the vulnerable function. To run this PowerShell script, you’ll need to install PowerShell if you’re not using Windows 7 (PowerShell comes with Windows 7), and you’ll need to install the .NET Framework SDK or Visual Studio, and finally update the first line of the script to point to the location that ildasm.exe was installed on your computer.
$PathToILDASM = "C:\Program Files\Microsoft.NET\SDK\2.0\Bin" $FilesToScan = get-childitem -Filter *.exe -Recurse$FilesToScan += get-childitem -Filter *.dll -Recurse "Found " + $FilesToScan.Count + " EXE and DLL file(s) to scan""""Binaries that contain calls to System.Security.Cryptography.Xml.SignedXml.CheckSignature(KeyedHashAlgorithm macAlg):" foreach($File in $FilesToScan) { $FileName = $File.FullName if (([string]$FileName).Length -gt 0) { $Process = New-Object -typeName System.Diagnostics.Process $Process.StartInfo.WorkingDirectory = (get-location).Path $Process.StartInfo.UseShellExecute = $false $Process.StartInfo.RedirectStandardOutput = $true $Process.StartInfo.RedirectStandardError = $true $Process.StartInfo.FileName = [System.IO.Path]::Combine($PathToILDASM, "ildasm.exe") $Process.StartInfo.Arguments = "/OUT=temp.txt `"$FileName`" /NOBAR" $Process.Start() | out-null $Process.WaitForExit() if (Test-Path temp.txt) { $Disassembly = Get-Content temp.txt del temp.txt if (([string]$Disassembly).Contains("callvirt instance bool [System.Security]System.Security.Cryptography.Xml.SignedXml::CheckSignature(class [mscorlib]System.Security.Cryptography.KeyedHashAlgorithm)")) { $File.FullName } } }} Acknowledgements
$PathToILDASM = "C:\Program Files\Microsoft.NET\SDK\2.0\Bin"
$FilesToScan = get-childitem -Filter *.exe -Recurse$FilesToScan += get-childitem -Filter *.dll -Recurse
"Found " + $FilesToScan.Count + " EXE and DLL file(s) to scan""""Binaries that contain calls to System.Security.Cryptography.Xml.SignedXml.CheckSignature(KeyedHashAlgorithm macAlg):"
foreach($File in $FilesToScan) { $FileName = $File.FullName if (([string]$FileName).Length -gt 0) { $Process = New-Object -typeName System.Diagnostics.Process $Process.StartInfo.WorkingDirectory = (get-location).Path $Process.StartInfo.UseShellExecute = $false $Process.StartInfo.RedirectStandardOutput = $true $Process.StartInfo.RedirectStandardError = $true $Process.StartInfo.FileName = [System.IO.Path]::Combine($PathToILDASM, "ildasm.exe") $Process.StartInfo.Arguments = "/OUT=temp.txt `"$FileName`" /NOBAR" $Process.Start() | out-null $Process.WaitForExit() if (Test-Path temp.txt) { $Disassembly = Get-Content temp.txt del temp.txt if (([string]$Disassembly).Contains("callvirt instance bool [System.Security]System.Security.Cryptography.Xml.SignedXml::CheckSignature(class [mscorlib]System.Security.Cryptography.KeyedHashAlgorithm)")) { $File.FullName } } }}
Thanks to Shawn Farkas, Damian Hasse, Joe Hemmerlein, Alex Lucas, and Andrew Roths for their help with this blog post!
-Kevin Brown, MSRC Engineering
Today we released the fix for CVE-2010-0816 in MS10-030. This vulnerability affects Outlook Express, Windows Mail, and Windows Live Mail. We recommend that you install the update as soon as possible, but realize that some customers may need to prioritize which updates they install first. While the vulnerability is rated critical, many customers may not be affected by it. This blog post should help you better understand the risk associated with this vulnerability.
Windows 7
Default installations of Windows 7 are not affected by this vulnerability because they do not include Windows Live Mail. Windows Live Mail is available as a free download for Windows 7, but is not included in the operating system by default.
Attack scenarios
Non-vulnerable scenarios
Attack vector details
Summary of risk
Acknowledgements
Thanks to Andrew Roths, Damian Hasse, and Fermin J. Serna for their contributions to this blog post.
We hope you found this information helpful!
Today we released bulletin MS10-031 addressing vulnerability CVE-2010-0815 in the VBE6.DLL library. VBE6.dll is part of Visual Basic Environment and can be used by many Microsoft products, including Microsoft Office. We wanted to share a little more detail about this vulnerability to help you make a risk decision regarding its exploitability.
The vulnerability is a one-byte stack overwrite due to a code defect in text parsing code, with three additional conditions limiting attacker’s control:
In theory there are a few ways this vulnerability could be used in a successful exploit, yet all of them require very specific properties of the program (for an example: return address that does not start with 0x00 and includes 0x2e and after turning 0x2e into 0x00 points to a code usable by an exploit). Such properties, while possible, are unlikely to be found in practice.
In our analysis, we feel that consistent exploit code resulting in arbitrary code execution is not likely to be released within the next 30 days. However, following our general guidelines, we have classified this vulnerability as exploitable with possibility for code execution.
- Greg Wroblewski, MSRC Engineering