Freigeben über

Understanding Problems with MS10-049, KB 980436 and IETF RFC5746

  • Artikel

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: https://tools.ietf.org/html/rfc5746 https://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:

1. The non-compliant server may not renegotiate leaving it vulnerable to CVE-2009-3555

2. TLS requires servers to accept extended client hello messages, even if the server does not "understand" the extension (https://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:

clip_image001

If the server is OK with the ClientHello it will return a Server Hello like this:

clip_image002

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:

clip_image003

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):

clip_image004

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:

clip_image005

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.

Comments

  • Anonymous
    September 10, 2010
    For those who haven't read the RFC Draft, SCSV stands for "Signalling Cipher Suite Value":   "This SCSV is not a true cipher suite ... instead it has the same semantics as an empty "renegotiation_info" extension, ...   ("Because SSLv3 and TLS implementations reliably ignore unknown cipher suites, the SCSV may be safely sent to any server.")

  • Anonymous
    September 17, 2010
    Does the UseScsvForTls registry setting work on Windows 2008R2?

  • Anonymous
    October 04, 2010
    Mike, It should!

  • Anonymous
    November 03, 2010
    I've got a customer who's using webMethods Integration Server and he's facing this issue as well. Does he need to request a patch for webMethods? Also does your workaround need to be done at client side? It's a Win2k3 x86 Server SP3 for the server but client side could be any desktop OS.

  • Anonymous
    November 03, 2010
    That server is built on open source I believe.  The problem would be with the openSSL library.  He can build get the openSSL library himself and rebuild the code for the server.  He can also request a fix from the vendor.  Every client that calls the server could also be patched as an alternative.  Obviously patching every client is not a great idea gut it is possible.

  • Anonymous
    October 02, 2012
    It looks like we are bumping into this issue as well. JPSanders, is there any way that we can discuss this further via PM?  My team has several questions regarding the behavior of this patch and how we can work around the issues we are seeing.

  • Anonymous
    October 02, 2012
    Hi Dan, This article should be fairly complete however you can certainly open a support case to discuss this further. support.microsoft.com/oas -Jeff

  • Anonymous
    October 02, 2012
    Thanks.  Was trying to avoid that, but it's really looking like we are seeing the issue when calling from .NET or C# (demonstrable). Will open a ticket....