So Win7 isn't affected? At this point in time I have to point out a fully patched Win7, having ~8 hours of support life left, just happens to be more secure than Win10 for trusting certs.
Patch Critical Cryptographic Vulnerability in Microsoft Windows [pdf]
91–100 of 235 posts
Re: Patch Critical Cryptographic Vulnerability in Microsoft Windows [pdf]
#92From a conversation with Thomas Pornin, a plausible explanation given the details provided in the DoD advisory: Given an ECDSA signature and control over the curve domain parameters, it's straightforward to create a second private key that matches the original public key, without knowledge of the original signing private key. Here's how: To start with, you need to understand a little bit about how curve cryptography…
I hope that the actual vulnerability is far more complicated. If we can't even get crypto libraries right (where you'd hope most of the formal verification folks are), then there's not much hope of security for the rest of the industry. I'm normally not much of a pessimist but things like this really make me wish we could just burn all the things and start over.
There's a history of vulnerabilities like these, in some of the most important crypto libraries. For instance: until 2008, NSS, the TLS library used by Firefox, couldn't properly validate RSA signatures from e=3 RSA keys (it wasn't validating the full signature block, but rather parsing it and looking for the embedded hash). For e=3 roots, which were readily available at the time, you could simply build any signature block you wanted and then take its cube root.
Re: Patch Critical Cryptographic Vulnerability in Microsoft Windows [pdf]
#93Oh great. Mozilla just added last week an option for entreprises to enable trusting of system certificates on Windows. See Firefox 72.0 release notes: https://www.mozilla.org/en-US/firefox/72.0/releasenotes/
Note that from the release note the new option just allows to read certificates from the system store. Validation is still done by Firefox, so NSS crypto lib, not crypt.dll. So even if the option is enabled Firefox is not affected by the vulnerability (except for code signing check of the Firefox binary itself by the OS).
Re: Patch Critical Cryptographic Vulnerability in Microsoft Windows [pdf]
#94Re: Patch Critical Cryptographic Vulnerability in Microsoft Windows [pdf]
#95Interesting comment on reddit: > Within the federal space, we've been making unprecedented plans for patching systems as soon as this patch is released today. In my agency we're going to be aggressively quarantining and blocking unpatched systems beginning tomorrow. This patch has been the subject of many classified briefings within government agencies and military. https://old.reddit.com/r/sysadmin/comments/eoll74/a…
The Department of Homeland Security issued an emergency directive today for federal agencies to patch their systems within 10 business days:
Re: Patch Critical Cryptographic Vulnerability in Microsoft Windows [pdf]
#96I suspect you're overcomplicating the attack with all the math and we can ignore most of it.
The only way the attacker can tell the MS Crypto API is via the TLS protocol. You can only do it if it's relevant. The only option for that is to use ECDH, which allows the server to supply EC parameters for the Diffie-Hellmann exchange.
My bet is that the problem is that MS Crypto API took those parameters as correct without checking them against what's in the certificate. I.e.,
ServerKeyExchange - here's the EC spec, we just need the public key Certificate - ah - here's public key, we have the ECparams - let's run the math
:)
Re: Patch Critical Cryptographic Vulnerability in Microsoft Windows [pdf]
#97Earlier quoted context omitted.
I hope that the actual vulnerability is far more complicated. If we can't even get crypto libraries right (where you'd hope most of the formal verification folks are), then there's not much hope of security for the rest of the industry. I'm normally not much of a pessimist but things like this really make me wish we could just burn all the things and start over.
There's a history of vulnerabilities like these, in some of the most important crypto libraries. For instance: until 2008, NSS, the TLS library used by Firefox, couldn't properly validate RSA signatures from e=3 RSA keys (it wasn't validating the full signature block, but rather parsing it and looking for the embedded hash). For e=3 roots, which were readily available at the time, you could simply build any signature…
Bleichenbacher'06 never dies.
Re: Patch Critical Cryptographic Vulnerability in Microsoft Windows [pdf]
#98None of these links describe how the exploit works. I found this: https://media.defense.gov/2020/Jan/14/2002234275/-1/-1/0/CSA... So based on my limited understanding: 1. The certificates have a place for defining curve parameters. 2. The attacker specifies their own parameters so that they match the start of a standard curve but choose the rest of the parameters themselves. With the right ECC math they are able to g…
Good find. This page should almost certainly be the headline article on HN, at least until someone does a full write-up of the vulnerability --- but the vulnerability here looks very simple (and gross ): if you can define your own curve parameters and get CryptoAPI to honor them, you can sign anything.
The only way to do it (I'm lazy so didn't read any of the documents - my gut feeling of an engineer) ... is to use ECDH, which provides EC params in ServerKeyExchange. CryptoAPI might have used those and just pull the public key from the cert.
Re: Patch Critical Cryptographic Vulnerability in Microsoft Windows [pdf]
#99The advisory from Microsoft is quite bizarre. It focuses on code signature validation, rather than X.509 as a whole. It also doesn't say anything about how the vulnerability itself works. Vague advisories like this are dangerous, because it gives adversaries an advantage over IT departments that don't know which system they should patch first. It would be much better if everyone understood exactly what the impact is…
X509 as a whole is fine and this isn't so much arbitrary MITM of any web server. It's specific to ECC public keys(not specifically X509 certs) that validate from cryptoAPI which is a fairly limited but devastating scope. EG Code signing.
Firefox uses its own NSS libraries not cryptoAPI to verify certs and is completely unaffected. I assume every major browser uses NSS or their own APIs as well. And of course RSA and AES certificates remain unaffected.
Re: Patch Critical Cryptographic Vulnerability in Microsoft Windows [pdf]
#100Earlier quoted context omitted.
That depends on whether Windows Update is using ECC certificates. A quick scan of my Windows 10 trusted root certificate store shows almost exclusively RSA based certificates, so I’d guess 80% odds that Windows Update itself isn’t affected.
It may still be affected, the system may accept a bad ECC cert and override the RSA cert.
This is pure speculation and garbage.