Earlier quoted context omitted.
but only shortname curves
Does that mean it's unaffected?
I would expect everything not patched today is unaffected for such a reason yes.
Patch Critical Cryptographic Vulnerability in Microsoft Windows [pdf]
151–160 of 235 posts
Re: Patch Critical Cryptographic Vulnerability in Microsoft Windows [pdf]
#152Earlier quoted context omitted.
Mobile users: there is a “p” at the end of the equation, it is hidden due to the type of code formatting that HN uses.
In fact, exactly what is hidden will vary depending on your device and font size. You can scroll the code block horizontally to see what's hidden, or here is the equation without code formatting: y^2 = x^3 + ax + b mod p
So really, the problem is more that the horizontal scroll bar is hidden by default.
Re: Patch Critical Cryptographic Vulnerability in Microsoft Windows [pdf]
#153It's been reported that Windows Defender can detect and report on malicious certificates: https://twitter.com/AmitaiTechie/status/1217156973268893696 Of course, that relies on not having Defender disabled by an alternate product.
On Windows Server 2016 and newer it stays enabled even with an “alternate product.”
https://docs.microsoft.com/en-us/windows/security/threat-pro...
> In Windows Server 2016, Windows Defender AV will not disable itself if you are running another antivirus product.
Re: Patch Critical Cryptographic Vulnerability in Microsoft Windows [pdf]
#154Earlier quoted context omitted.
So the mitigation would be to add a check that the generator point in (for example) a CertificateVerify message is the one in the p256 spec (or otherwise the one on the cert, I’m not deep enough to know where it usually lives)?
In practice this means rejecting the "specifiedCurve" choice in ASN.1 ECParameters. ASN.1-based protocols are the only ones I'm aware of that permit specifying an arbitrary curve. For the PKIX ASN.1 standard(s) old-style EC public keys are specified with an ECParameters field: ECParameters ::= CHOICE { namedCurve OBJECT IDENTIFIER implicitCurve NULL specifiedCurve SpecifiedECDomain } PKIX, which is what TLS and most…
It's not even that: the AlgorithmIdentifier structure in the SubjectPublicKeyInfo is allowed to contain parameters, the one in the Signature should not. This is arguably a spec bug.
Re: Patch Critical Cryptographic Vulnerability in Microsoft Windows [pdf]
#155I'm assuming there will never be an official proof of concept release, so how long do you all think it will be before we see widely available exploit code and fake certificates out in the wild?
Re: Patch Critical Cryptographic Vulnerability in Microsoft Windows [pdf]
#156Earlier quoted context omitted.
"enable remote code execution." suggests it's worse than that - like the curve parameters might allow a buffer overflow, or something of that nature. Maybe they just mean because it can sign Authenticode signatures
The attack allows faking https certs as well as code signing certs; so it seems plausible that a MitM attacker could trick Windows Update (or other auto-updaters) into executing malicious code.
What about user certs. Some windows systems allow for authenticating with a user cert. depending on how bad the validation bug is, seems like spoofing a user certificate could be a valid attack vector.
Re: Patch Critical Cryptographic Vulnerability in Microsoft Windows [pdf]
#157Earlier quoted context omitted.
In practice this means rejecting the "specifiedCurve" choice in ASN.1 ECParameters. ASN.1-based protocols are the only ones I'm aware of that permit specifying an arbitrary curve. For the PKIX ASN.1 standard(s) old-style EC public keys are specified with an ECParameters field: ECParameters ::= CHOICE { namedCurve OBJECT IDENTIFIER implicitCurve NULL specifiedCurve SpecifiedECDomain } PKIX, which is what TLS and most…
It's not even that: the AlgorithmIdentifier structure in the SubjectPublicKeyInfo is allowed to contain parameters, the one in the Signature should not. This is arguably a spec bug.
There's even a timely question about this to m.d.s.policy as a result of a Mozilla policy revision which spells out byte-by-byte what a conformant AlgorithmIdentifier looks like:
https://groups.google.com/forum/#!topic/mozilla.dev.security...
This gave Ryan a chance to point people at Adam Langley's wise observation that you should not parse things like signatures when you can instead calculate the entire value you expected and then just binary compare - anything that doesn't match is wrong and you needn't care why.
Re: Patch Critical Cryptographic Vulnerability in Microsoft Windows [pdf]
#158Earlier quoted context omitted.
We need one time pads. They're the only really trustworthy crypto.
Hmm. Maybe I'll generate some high quality OTPs for myself with a good CSPRNG. I could use any decent block cipher in counter mode, just need to guard against counter re-use, and then ship my OTPs off to anyone I need to communicate with. Hang on, if I could come up with a way of securely sharing the key I used with my recipient, I wouldn't need to actually mail the OTP to them, since they could generate it themselve…
> Maybe I'll generate some high quality OTPs for myself with a good CSPRNG
That's not a one-time pad, it's simply a stream cipher.
Re: Patch Critical Cryptographic Vulnerability in Microsoft Windows [pdf]
#159It's been reported that Windows Defender can detect and report on malicious certificates: https://twitter.com/AmitaiTechie/status/1217156973268893696 Of course, that relies on not having Defender disabled by an alternate product.
On Windows Server 2016 and newer it stays enabled even with an “alternate product.” https://docs.microsoft.com/en-us/windows/security/threat-pro... > In Windows Server 2016, Windows Defender AV will not disable itself if you are running another antivirus product.
True, but imagine you deployed SEP in accordance with supplier's instructions:
https://support.symantec.com/us/en/article.tech237177.html
Or Mcafee:
https://kc.mcafee.com/corporate/index?page=content&id=KB8245... (search for DisableRealtimeMonitoring)
For a deeper dive: I ran into issues on a security assessment trying to run procdump on lsass being blocked by Defender. Workaround.. was to find a machine with McAfee installed where that behavior was allowed.
Re: Patch Critical Cryptographic Vulnerability in Microsoft Windows [pdf]
#160Earlier 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.
> just burn all the things and start over Wrap all of this with an "IN MY OPINION"... That would make things worse because we'd make the same mistakes again. I've been on many start over projects (Xeon Phi, for example, threw out the P4 pipeline and went back to the Pentium U/V). It doesn't work. You know what the most robust project I've worked on? The instruction decoder on Intel CPUs. The validation tests go back…