Understanding Problems With Ms10 049 Kb 980436 And Ietf Rfc5746
- 08 Sep 2010
Understanding Problems with MS10-049, KB 980436 and IETF RFC5746
Microsoft released a Security update MS10-049: Vulnerabilities in SChannel could allow remote code execution. This update patches vulnerabilities in SChannel (TLS) that can be exploited (see: CVE-2009-3555). Read the RFC and CVE articles to understand what vulnerability this is addressing: http://tools.ietf.org/html/rfc5746 http://tools.ietf.org/html/draft-ietf-tls-renegotiation-03
There are some ancient servers still out in the wild however that do not correctly ignore ClientHelloExtensions that they do not understand. According to the RFCs they should ignore the unknown extensions, but they are not compliant. The obvious workaround is to upgrade those servers so that they do not barf on the unknown extensions, but there may be cases where you do not have control over the target servers or cannot convince the owners to upgrade to a fixed version.
There are two problems you may see from non compliant servers:
-
The non-compliant server may not renegotiate leaving it vulnerable to CVE-2009-3555
-
TLS requires servers to accept extended client hello messages, even if the server does not “understand” the extension (http://tools.ietf.org/html/draft-ietf-tls-rfc3546bis-02). The non-compliant server may refuse the SSL connection if it does not correctly understand the extended client hello messages and not allow you to establish a connection.
For both of these problems the fix should be to UPDATE the problem server. All major 3rd parties do have updates that comply to this so you should contact the vendors for update information.
Layman’s explanation
To remove this vulnerability (CVE-2009-3555), IETF RFC5746 recommends using the ClientHelloExtension with Renegotiation Info. Bad evil servers that are not RFC3546 compliant do not ignore this extension and therefore will send back an encrypted alert. You will see this in a Netmon trace when you have enabled only TLS in the advanced options of IE and try to hit an https://somebadSite.
Identify if you are seeing the issue
So that you do not cry ‘wolf’ and blame this update on your TLS woes, I will show you what to look for in a Netmon or wireshark trace to identify if you are falling under this problem, and then some options to work around the issue. WinInet, WinHTTP, and HttpWebRequest application implementations that make SSL requests over HTTP (HTTPS) are using SChannel, so they may experience this problem after installation of MS10-049. This could also affect raw SSL traffic.
Start Netmon and look for the client hello (apply TLS as a filter):
TLS: TLS Rec Layer-1 HandShake: Client Hello.
Expand this out and notice the highlighted information below:
If the server is OK with the ClientHello it will return a Server Hello like this:
Here you will see that the server responded to the Client Hello with an Encrypted Alert which means in this case that it does not like the format of the Client Hello:
This is the first indicator of the problem.
The fix is to make sure that the server is updated and will not fall victim to the vulnerability. An IIS 6 server that is not patched will not send the Encrypted Alert, but it will simply ignore this Extension. You must update your servers to be protected (or convince the target server owner to patch their server). All major servers have recent patches or updates for this vulnerability.
What can I do in the short term?
NOTE: These are ALL SHORT term fixes.
There are several things you can do client side to get around this issue.
Apply the registry setting in KB 980436
This does NOT work with Windows 7
Selecting the Signaling mechanism for Windows Server 2008, Windows Vista, Windows Server 2003, and Windows XP only
The RFC5746 recommends sending the TLS Renego extension in the TLS Client Hello packet at the client. However, in some cases, there might be the need to send SCSV for signaling in its TLS Client Hello packet. An administrator can use the UseScsvForTls entry DWORD value together with a nonzero value in the following registry path to send SCSV for signaling in TLS:
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\SecurityProviders\SCHANNEL
The following table shows how this DWORD value can be used:
Collapse this tableExpand this table
|
DWORD |
Value = zero |
Value = nonzero |
|
UseScsvForTls |
Client sends Renego Info extension for TLS protocol |
Client sends SCSV for TLS protocol |
For example, to get around the TLS Client Hello Extension problem (on non compliant target server) create a DWORD registry value and set the value to 1:
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\SecurityProviders\SCHANNEL\UseScsvForTls
Reboot and validate that instead of the ClientHelloExtension being sent, the flag is sent as a TLSCipherSuite 255 (0xFF):
This should keep the non-compliant server from choking.
You can also set this for your application if it is using WinInet, WinHttp or Managed code instead of for the entire machine
For WinINet based applications (like IE) use the SSL3 Protocol instead of TLS.
In IE this is under the Advanced Settings:
In managed code use the ServicePointManager before making any requests:
ServicePointManager.SecurityProtocol = SecurityProtocolType.Ssl3;
For WinHttp you can set this option in your code: WINHTTP_OPTION_SECURE_PROTOCOLS
If this is a third party library, you need to engage that 3rd party and ask them how you can set their classes so that they can use SSL3 instead of TLS!
Again, this is only temporary. Fix the Server! OpenSSL, Apache etc.. all have fixes for this (see CVE-2009-3555 for links to your product).
What are the other registry keys listed in MS10-049?
You can force the strict communication by setting the client and/or server to strict mode so you know you will not be vulnerable to CVE-2009-3555.
Please let me know if you found this article helpful.
<< Go Back