Workaround for .NET Bug

Thursday, July 30, 2015 @ 03:07 PM gHale

Microsoft created a workaround for a vulnerability in the .NET Framework 4.6 that can result in incorrect parameters, with unpredictable results.

It can affect any .NET 4.x application, but once the .NET Framework 4.6 ends up installed, only those running in 64-bit processes, said Microsoft program manager Rich Lander in a blog post. He did add most applications will not suffer from the issue.

Zero Day for Apple App Store, iTunes
Mobile IE Zero Days
Microsoft Fixes New Windows Zero Day
Microsoft Patches Zero Day Holes

“This issue is narrow in nature. Your code has to use specific data types, pass them in specific ways and execute specific operations. Very few programs will satisfy all of these characteristics, which is required to trigger this codegen bug.

“We have reviewed this issue to determine if it is exploitable. We have not identified an exploit, but are pushing the change through our process at the same pace as we would an exploit.”

Lander said the .NET team concluded a detailed analysis of tens of thousands of test assets and internal customer data. The data suggests the vast majority of .NET developers will not experience this same issue. We have extensive tests for the .NET Framework libraries (e.g. System.Xml). We have not been able to find a single case of this issue across that very large body of code. From a production standpoint, big Microsoft web properties have been running on pre-release versions of .NET Framework 4.6 for months without hitting this issue.

“This bug requires a significant set of conditions that must be present to trigger it. It’s unlikely developers have actually written matching code. We recognize this bug is very real to StackExchange, and conclude they are one of the few cases that have and will hit it,” Lander said.

Lander said the recommendation to StackExchange and to any other user is the following:
1. Scout the .NET Framework 4.6 in your environment.
2. If you run into an issue that you cannot diagnose, try disabling RyuJIT.
3. If disabling RyuJIT resolves the issue, please re-enable RyuJIT and disable tail call optimization.
4. If your issue is mitigated with the tail call optimization disabled, then you know that your app is subject to this issue. You can run your app in production in that configuration (tail call optimization disabled), to get the other .NET Framework 4.6 benefits. This work around will disable only the tail call optimization feature and should not negatively impact performance.
5. If your issue is not mitigated with the tail call optimization disabled, but is mitigated with RyuJIT disabled, we want to hear from you on .NET Framework Connect. You can also run your app in production in this configuration (RyuJIT disabled).
6. If your issue is not mitigated by disabling RyuJIT or tail call optimization, then it something else and unrelated to this advisory.