11 ms·

Vulnerability in Microsoft TLS library could allow remote code execution

300 points by molf 12y ago

aluhut 12y ago
4 hours for 5MB? Wow...
0x0 12y ago
Is this the beginning of another sasser/codered worm?
yuhong 12y ago
Wonder why didn't they add GCM with ECDHE even though it is already in Win10 preview. I considered it strange that they added GCM with DHE in the first place when all the rest of the suites are ECDHE.
- mike_hearn 12y ago
  From the article: Does this update contain any additional security-related changes to functionality? Yes. In addition to the changes that are listed in the Vulnerability Information section of this bulletin, this update includes changes to available TLS cipher suites. This update includes new TLS cipher suites that offer more robust encryption to protect customer information. These new cipher suites all operate in Galois/counter mode (GCM), and two of them offer perfect forward secrecy (PFS) by using DHE key exchange together with RSA authentication.
  - Perseids 12y ago
    I don't see the relevance of the quote. It only states the changes and not why other changes were not made.
- higherpurpose 12y ago
  Too bad they didn't add support for ChaCha20 and Poly1305 https://www.imperialviolet.org/2013/10/07/chacha20.html https://www.imperialviolet.org/2013/10/07/chacha20.html Also, did they even add support for Curve25519? Or are they still forcing us all to trust the (almost certainly) tainted NIST curves?
  - Strom 12y ago
    While ChaCha20/Poly1305/Curve25519 are nice, they aren't part of standard TLS, and even OpenSSL doesn't support them.
- m0dest 12y ago
  Agree, this is super strange. No one wants to use DHE because of the performance impact. Windows 7 and later do already support ECDHE + GCM, but only when combined with ECDSA. In practice, nobody can use ECDSA because old clients still need RSA certificates. So we continue to wait for TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256, which is clearly the cipher suite that everyone wants. Years later, still not available for Windows Server.
executive 12y ago
could allow? or allows?
- 13 12y ago
  Go with the assumption that it does.
codys 12y ago
I'm interested in knowing if this affects Windows XP. From the page: > Other versions or editions are either past their support life cycle or are not affected And XP is unlisted. Seems to imply that it could be either one.
- yuhong 12y ago
  Well, Server 2003 is very similar to WinXP and I think http://support.microsoft.com/kb/894199 http://support.microsoft.com/kb/894199 lists a WEPOS/POSReady 2009 version.
- ams6110 12y ago
  XP is not supported. Why would they make a statement one way or the other?
  - hueving 12y ago
    To face the reality that there are a ton of XP deployments. It would be in Microsoft's interest to at least notify them of the problem and even incentivize them to upgrade.
    - tracker1 12y ago
      Well, XP likely has the same issues in their implementation, given similar origins, especially for older protocols. XP requires SP3 for TLS1 iirc, and doesn't support > TLS 1.0, let alone 1.1 or 1.2 (current). There are other issues with browsers (namely that a lot of XP users are still using IE8, which has a host of other issues). The project I am now on isn't supporting IE8, we're going to load some HTML5/ES6 shims, and a notice to users that it may not work, but given how poorly MS's VMs for testing IE8 on XP are, it's really a non-starter. IE8 is about 3-4% of our current traffic, which will likely be displaced by mobile traffic once our site/app is no longer mobile hostile. I wouldn't consider XP a viable OS at this point, and many users would be better off with a more recent ubuntu, and wine.
mike_hearn 12y ago
After Heartbleed, I decided to run a Java servlet container as my direct web server so I can use JSSE rather than OpenSSL or some other SSL stack written in C. It seems to me that if you can, an SSL stack written in a safe language is not a bad idea. JSSE is pretty modern though doesn't support every possible feature (it's missing OCSP stapling at the moment). But it can do forward secrecy and AES-GCM. I get an A- from the Qualys test: for some reason PFS doesn't work with IE and it doesn't like that my cert has a SHA1 based signature (I'll go get my cert reissued at some point). Oh and the SCSV fallback hack is missing. Otherwise it's doing OK. And ... no buffer overflows.
- diminoten 12y ago
  How performant is that setup, out of curiosity? I've always assumed the tradeoff here is a safe language is slower, and slow crypto is no bueno.
  - bhauer 12y ago
    We (TechEmpower) have run preliminary tests of JSSE in consideration of a future round of our framework benchmarks project. Although we do not yet have any SSL tests in our project, our preliminary findings were that JSSE was considerably higher-performance than we had been lead to believe by popular opinion. I don't have the data in front of me, but using JSSE in lieu of OpenSSL did not affect request-per-second results sufficiently to make me worry about using JSSE. Since then, my chief concern with JSSE has been simply not knowing how solid it is from a correctness of the algorithms perspective, but that is something I'm not well versed in. In other words, my concern was just one of uncertainty. Provided a credible security analysis suggests JSSE is just as secure (if not moreso) than alternatives in unsafe languages, I will be confident deploying future apps on JSSE.
  - frankchn 12y ago
    May I ask why not? I would personally prefer slower (if safer) crypto over fast but potentially vulnerable crypto.
  - mike_hearn 12y ago
dmix 12y ago
Triggers the tptacek bat signal (or other kind infosec people) How worried should people reasonably be?
- swartkrans 12y ago
  Well it's patched now, but it didn't affect you unless you were running a "Windows Server" although all recent operating systems were affected. If your Windows machine is behind your home router and you were not forwarding ports to it you're probably fine. I doubt this vulnerability was known well enough that enough people were scanning for vulnerable IPs to exploit them.
  - xnull 12y ago
    The window from disclosure of patches to duplication is narrowing and it appears from the bulletin that client connections are affected as well. Furthermore any computer you take anywhere outside your home router (and can you really trust your home router as security boundary nowdays?!) will be easy to manipulate into an SChannel connection. Inside your home network, clients are still vulnerable to attack - any javascript/flash ad/referer can point a computer behind a router at an attacker server and serve up malicious SChannel packets. That is to say your home computer can be attacked on outgoing connections which your router will be happy to allow. It's very serious. Patch immediately.
    - ars 12y ago
      Does this also affect firefox on XP? Does firefox use the Windows TLS library, or does it have its own?
      - xnull 12y ago
        It has its own ("Network Security Services" or NSS). But that's not a reason to use Firefox on XP. ;)
- jeffmcjunkin 12y ago
  I'm not tptacek, but right now I think the answer is: "We don't know." There isn't an acknowledged proof-of-concept, so we're not sure that it's exploitable. It hasn't been made clear whether it's wormable, either. My bet is it will affect XP if it's exploitable, but only for those who added IIS (not default, and not terribly common). It will likely remain unpatched forever, as Microsoft is unlikely to send a patch to an "unsupported" OS again, like they did with the Internet Explorer 0-day [0] [0]: http://blogs.technet.com/b/msrc/archive/2014/05/01/out-of-band-release-to-address-microsoft-security-advisory-2963983.aspx http://blogs.technet.com/b/msrc/archive/2014/05/01/out-of-ba...
mpyne 12y ago
No acknowledgement of the source, either in the Technet article or the security bulletin's acknowledgements. I wonder who the private source must be that would ask for anonymity?
- deleted 12y ago
  [deleted]
- stusmall 12y ago
  Here[1] I saw that it was from an internal audit. [1] http://blogs.technet.com/b/srd/archive/2014/11/11/assessing-risk-for-the-november-2014-security-updates.aspx http://blogs.technet.com/b/srd/archive/2014/11/11/assessing-... EDIT: Added a better source.
servowire 12y ago
The attack vector is a bit vague, and I'm not sure how to bring this news to some of my clients. Is the exploit only for when running services on/to the internet (IIS, Exchange webmail, etc - ) , or is visiting an https (TLS) website on and end-user enough to make the exploit happen (even in Firefox/Chrome and behind a tradional proxy server). Sadly Microsoft does not explain the exact parameters that make this exploit tick - this makes risk assessment hard.
- el_duderino 12y ago
  Indeed it does make it tricky, but I think they purposely left out some details for the time being. See more: http://adi.is/winshock.txt http://adi.is/winshock.txt
Robin_Message 12y ago
We upgraded to this, only to find it activates some new encryption modes (4 new GCM suites) that seem to cause RST packets when used. Anyone else seen that issue? (Technical details: If the client offer one of the suites, the server is accepting it in the ServerHello, but then RSTing the connection after the client sends their encrypted handshake, and the event log says "none of the cipher suites supported by the client application are supported by the server". Browser and curl don't use that suite, but Amazon ELB does.)

300 points by molf 12y ago

aluhut 12y ago

4 hours for 5MB? Wow...

0x0 12y ago

Is this the beginning of another sasser/codered worm?

yuhong 12y ago

Wonder why didn't they add GCM with ECDHE even though it is already in Win10 preview. I considered it strange that they added GCM with DHE in the first place when all the rest of the suites are ECDHE.

mike_hearn 12y ago
From the article: Does this update contain any additional security-related changes to functionality? Yes. In addition to the changes that are listed in the Vulnerability Information section of this bulletin, this update includes changes to available TLS cipher suites. This update includes new TLS cipher suites that offer more robust encryption to protect customer information. These new cipher suites all operate in Galois/counter mode (GCM), and two of them offer perfect forward secrecy (PFS) by using DHE key exchange together with RSA authentication.
- Perseids 12y ago
  I don't see the relevance of the quote. It only states the changes and not why other changes were not made.
higherpurpose 12y ago
Too bad they didn't add support for ChaCha20 and Poly1305 https://www.imperialviolet.org/2013/10/07/chacha20.html https://www.imperialviolet.org/2013/10/07/chacha20.html Also, did they even add support for Curve25519? Or are they still forcing us all to trust the (almost certainly) tainted NIST curves?
- Strom 12y ago
  While ChaCha20/Poly1305/Curve25519 are nice, they aren't part of standard TLS, and even OpenSSL doesn't support them.
m0dest 12y ago
Agree, this is super strange. No one wants to use DHE because of the performance impact. Windows 7 and later do already support ECDHE + GCM, but only when combined with ECDSA. In practice, nobody can use ECDSA because old clients still need RSA certificates. So we continue to wait for TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256, which is clearly the cipher suite that everyone wants. Years later, still not available for Windows Server.

executive 12y ago

could allow? or allows?

13 12y ago
Go with the assumption that it does.

codys 12y ago

I'm interested in knowing if this affects Windows XP. From the page: > Other versions or editions are either past their support life cycle or are not affected And XP is unlisted. Seems to imply that it could be either one.

yuhong 12y ago
Well, Server 2003 is very similar to WinXP and I think http://support.microsoft.com/kb/894199 http://support.microsoft.com/kb/894199 lists a WEPOS/POSReady 2009 version.
ams6110 12y ago
XP is not supported. Why would they make a statement one way or the other?
- hueving 12y ago
  To face the reality that there are a ton of XP deployments. It would be in Microsoft's interest to at least notify them of the problem and even incentivize them to upgrade.
  - tracker1 12y ago
    Well, XP likely has the same issues in their implementation, given similar origins, especially for older protocols. XP requires SP3 for TLS1 iirc, and doesn't support > TLS 1.0, let alone 1.1 or 1.2 (current). There are other issues with browsers (namely that a lot of XP users are still using IE8, which has a host of other issues). The project I am now on isn't supporting IE8, we're going to load some HTML5/ES6 shims, and a notice to users that it may not work, but given how poorly MS's VMs for testing IE8 on XP are, it's really a non-starter. IE8 is about 3-4% of our current traffic, which will likely be displaced by mobile traffic once our site/app is no longer mobile hostile. I wouldn't consider XP a viable OS at this point, and many users would be better off with a more recent ubuntu, and wine.

mike_hearn 12y ago

After Heartbleed, I decided to run a Java servlet container as my direct web server so I can use JSSE rather than OpenSSL or some other SSL stack written in C. It seems to me that if you can, an SSL stack written in a safe language is not a bad idea. JSSE is pretty modern though doesn't support every possible feature (it's missing OCSP stapling at the moment). But it can do forward secrecy and AES-GCM. I get an A- from the Qualys test: for some reason PFS doesn't work with IE and it doesn't like that my cert has a SHA1 based signature (I'll go get my cert reissued at some point). Oh and the SCSV fallback hack is missing. Otherwise it's doing OK. And ... no buffer overflows.

diminoten 12y ago
How performant is that setup, out of curiosity? I've always assumed the tradeoff here is a safe language is slower, and slow crypto is no bueno.
- bhauer 12y ago
  We (TechEmpower) have run preliminary tests of JSSE in consideration of a future round of our framework benchmarks project. Although we do not yet have any SSL tests in our project, our preliminary findings were that JSSE was considerably higher-performance than we had been lead to believe by popular opinion. I don't have the data in front of me, but using JSSE in lieu of OpenSSL did not affect request-per-second results sufficiently to make me worry about using JSSE. Since then, my chief concern with JSSE has been simply not knowing how solid it is from a correctness of the algorithms perspective, but that is something I'm not well versed in. In other words, my concern was just one of uncertainty. Provided a credible security analysis suggests JSSE is just as secure (if not moreso) than alternatives in unsafe languages, I will be confident deploying future apps on JSSE.
- frankchn 12y ago
  May I ask why not? I would personally prefer slower (if safer) crypto over fast but potentially vulnerable crypto.
- mike_hearn 12y ago

dmix 12y ago

Triggers the tptacek bat signal (or other kind infosec people) How worried should people reasonably be?

swartkrans 12y ago
Well it's patched now, but it didn't affect you unless you were running a "Windows Server" although all recent operating systems were affected. If your Windows machine is behind your home router and you were not forwarding ports to it you're probably fine. I doubt this vulnerability was known well enough that enough people were scanning for vulnerable IPs to exploit them.
- xnull 12y ago
  The window from disclosure of patches to duplication is narrowing and it appears from the bulletin that client connections are affected as well. Furthermore any computer you take anywhere outside your home router (and can you really trust your home router as security boundary nowdays?!) will be easy to manipulate into an SChannel connection. Inside your home network, clients are still vulnerable to attack - any javascript/flash ad/referer can point a computer behind a router at an attacker server and serve up malicious SChannel packets. That is to say your home computer can be attacked on outgoing connections which your router will be happy to allow. It's very serious. Patch immediately.
  - ars 12y ago
    Does this also affect firefox on XP? Does firefox use the Windows TLS library, or does it have its own?
    - xnull 12y ago
      It has its own ("Network Security Services" or NSS). But that's not a reason to use Firefox on XP. ;)
jeffmcjunkin 12y ago
I'm not tptacek, but right now I think the answer is: "We don't know." There isn't an acknowledged proof-of-concept, so we're not sure that it's exploitable. It hasn't been made clear whether it's wormable, either. My bet is it will affect XP if it's exploitable, but only for those who added IIS (not default, and not terribly common). It will likely remain unpatched forever, as Microsoft is unlikely to send a patch to an "unsupported" OS again, like they did with the Internet Explorer 0-day [0] [0]: http://blogs.technet.com/b/msrc/archive/2014/05/01/out-of-band-release-to-address-microsoft-security-advisory-2963983.aspx http://blogs.technet.com/b/msrc/archive/2014/05/01/out-of-ba...

mpyne 12y ago

No acknowledgement of the source, either in the Technet article or the security bulletin's acknowledgements. I wonder who the private source must be that would ask for anonymity?

deleted 12y ago
[deleted]
stusmall 12y ago
Here[1] I saw that it was from an internal audit. [1] http://blogs.technet.com/b/srd/archive/2014/11/11/assessing-risk-for-the-november-2014-security-updates.aspx http://blogs.technet.com/b/srd/archive/2014/11/11/assessing-... EDIT: Added a better source.

servowire 12y ago

The attack vector is a bit vague, and I'm not sure how to bring this news to some of my clients. Is the exploit only for when running services on/to the internet (IIS, Exchange webmail, etc - ) , or is visiting an https (TLS) website on and end-user enough to make the exploit happen (even in Firefox/Chrome and behind a tradional proxy server). Sadly Microsoft does not explain the exact parameters that make this exploit tick - this makes risk assessment hard.

el_duderino 12y ago
Indeed it does make it tricky, but I think they purposely left out some details for the time being. See more: http://adi.is/winshock.txt http://adi.is/winshock.txt

Robin_Message 12y ago

We upgraded to this, only to find it activates some new encryption modes (4 new GCM suites) that seem to cause RST packets when used. Anyone else seen that issue? (Technical details: If the client offer one of the suites, the server is accepting it in the ServerHello, but then RSTing the connection after the client sends their encrypted handshake, and the event log says "none of the cipher suites supported by the client application are supported by the server". Browser and curl don't use that suite, but Amazon ELB does.)