Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Patch Critical Cryptographic Vulnerability in Microsoft Windows [pdf]

media.defense.gov

Post reply on HN
Print view View original

161–170 of 235 posts

Re: Patch Critical Cryptographic Vulnerability in Microsoft Windows [pdf]

#161

Post by tialaramex »

wahern wrote: post #130
an_account_name wrote: post #125

Earlier 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…

My guess is somebody at Microsoft responded to a customer need or claimed customer need to support specifiedCurve arguing that it was OK so long as said curve was a standard curve. I just don't see why you wouldn't stop at "PKIX forbids this, let's just not implement it" otherwise.

There probably aren't any such certificates out in the Web PKI because Mozilla's rules prohibit them (and almost as important Firefox won't validate them). But Microsoft trusts a whole bunch of dubious kinda sorta wanna be Certificate Authorities, maybe one of those issued crap with specifiedCurve for a standard curve ? Or maybe a corporate internal CA?

That's a test somebody can do: If you use a Microsoft internal CA can you easily mint these stupid specifiedCurve certificates with it? Or does it make you pick a named curve and emit the OID properly? How about other popular private CA solutions? EJBCA maybe?

Re: Patch Critical Cryptographic Vulnerability in Microsoft Windows [pdf]

#162

Post by Darkphibre »

0xff00ffee wrote: post #150
_hl_ wrote: post #88

Earlier 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…

It really pisses me off when devs start ripping out asserts and tests that fail "But have been doing so for a while, so clearly they aren't needed."

How about... no. Review the code and determine our undefined behavior is understood well enough that we can accept the bad inputs. Those asserts & tests were created for a reason, and need to be maintained. Not just removed because no one can spot the subtle failure modes.

Re: Patch Critical Cryptographic Vulnerability in Microsoft Windows [pdf]

#163

Post by schoen »

Tomte wrote: post #158
bscphil wrote: post #141

Earlier quoted context omitted.

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.

That's the joke!

Re: Patch Critical Cryptographic Vulnerability in Microsoft Windows [pdf]

#164

Post by tptacek »

tialaramex wrote: post #161
wahern wrote: post #130

Earlier 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…

My guess is somebody at Microsoft responded to a customer need or claimed customer need to support specifiedCurve arguing that it was OK so long as said curve was a standard curve. I just don't see why you wouldn't stop at "PKIX forbids this, let's just not implement it" otherwise. There probably aren't any such certificates out in the Web PKI because Mozilla's rules prohibit them (and almost as important Firefox won…

Who on earth has a corporate internal CA that issues certificates signed on non-standard curves? Who would ever do that? It's not like you're just a couple parameters away from Curve25519; a serious alternative curve will always come with alternative curve code.

Re: Patch Critical Cryptographic Vulnerability in Microsoft Windows [pdf]

#165

Post by quotemstr »

munchbunny wrote: post #107
_hl_ wrote: post #88

Earlier 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.

This stuff often looks simpler and less subtle in hindsight. Modern cryptography has gotten better at taking human (developer) error into account for designing secure API’s, but the fact of the matter is that the math is subtle, and cryptography in general is subtle due to the places where it collides with reality, so burning everything down and starting over is likely to just cause us to rediscover issues we already…

> cryptographic agility seems to cause more issues than the problems it solves,

Is that so? The ability to shift to new hash functions and ciphers within the bounds of a single protocol seems to have accelerated the adoption of better primitives.

Re: Patch Critical Cryptographic Vulnerability in Microsoft Windows [pdf]

#166

Post by tptacek »

monocasa wrote: post #147
tptacek wrote: post #136

Earlier quoted context omitted.

You've lost me. What are the glaring counterexamples to NOBUS? The NOBUS framework says that NSA introduces vulnerabilities and backdoors only when it has some assurance that only NSA will be able to exploit them. It doesn't follow that NSA would immediately disclose any vulnerabilities they discover.

...the parent is literally talking about it in the context of today's crypt vulnerability and using that as example of their cohesive NOBUS framework. > Clearly, no implementation flaw in Windows could qualify as a NOBUS backdoor; many thousands of people can read the underlying code in Ghidra or IDA and find the bug, once they're motivated to look for it. The counter examples are the hordes of critical 0 days they'v…

I don't think anyone should give NSA a cookie. I think it's useful to be able to reason through where NSA is (relatively) trustworthy and where they aren't.

Re: Patch Critical Cryptographic Vulnerability in Microsoft Windows [pdf]

#167

Post by SeekingMeaning »

_nedR wrote: post #160
0xff00ffee wrote: post #150

Earlier quoted context omitted.

> 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…

Yep : https://www.joelonsoftware.com/2000/04/06/things-you-should-...

> April 6, 2000

Wow. That goes waaaaaaay back. It’s crazy to think that 1980 was to him at the time as 2000 is to us _right now_.

Re: Patch Critical Cryptographic Vulnerability in Microsoft Windows [pdf]

#168

Post by jancsika »

bscphil wrote: post #141
mleonhard wrote: post #123

Earlier 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…

> Now, if only there were a secure method to share the key...

... that doesn't include a critical cryptographic vulnerability. :)

To be generous to the now greyed GP, there's probably a way to teach a recipient a short pad and its proper use so that the recipient can later decode a short ciphertext sent over Twitter. Perhaps even performing that feat in their head. None of the cryptography that could fit your quip has that property.

And if the recipient does something catastrophic like resend the pad over Twitter to confirm they memorized it correctly, there's at least a chance they may catch their error. Perhaps they may even correct it without the goddamned Department of Defense coming into it.

I don't get cryptographers' condescension toward OTP zealots. All they want is a better boat. At least have the decency of the captain from Titanic and apologize while we sink for not having delivered it.

Re: Patch Critical Cryptographic Vulnerability in Microsoft Windows [pdf]

#169

Post by makach »

_hl_ wrote: post #88
tptacek wrote: post #48

From 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.

Crypto is hard. Choose your libraries carefully, stay updated and for Zimmermann's sake: don't roll your own.

Re: Patch Critical Cryptographic Vulnerability in Microsoft Windows [pdf]

#170

Post by john_alan »

tptacek wrote: post #108
munchbunny wrote: post #107

Earlier quoted context omitted.

This stuff often looks simpler and less subtle in hindsight. Modern cryptography has gotten better at taking human (developer) error into account for designing secure API’s, but the fact of the matter is that the math is subtle, and cryptography in general is subtle due to the places where it collides with reality, so burning everything down and starting over is likely to just cause us to rediscover issues we already…

This is true, but the bug here is not subtle. It would have been shocking to discover an ECC implementation that let attackers specify curve parameters even 10-15 years ago. When we blogged the e=3 debacle back in '07 or whatever, we linked to a Kaliski presentation from 1999 that called out validating curve parameters. At least with the ACME vulnerability, there was a novel service model involved. Here, we're talkin…

Very interesting take. Good description of Pornins thoughts.

By the way, when you say closed src allowed... do other libs in the opensrc space check the curve Params?

Post reply on HN