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

201–210 of 235 posts

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

#201

Post by tialaramex »

john_alan wrote: post #170
tptacek wrote: post #108

Earlier quoted context omitted.

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?

Most people implementing ECC signatures are going to end up only handling a chosen group of named curves whereupon there aren't any curve parameters to check.

For example in Signal IIRC they use Curve25519. So there isn't any code about parsing or checking parameters, it's just here's some code that implements Curve25519.

NSS (the library used in Firefox on every platform) only accepts NIST's P-256 and P-384 named curves. It is parsing an ASN.1 data structure which can have parameters for curves, but if parameters are present instead of a name NSS's code gives up immediately because it's only looking for those specific names. (These aren't actually human readable names, they are OIDs such as 1.2.840.10045.3.1.7 for curve P-256)

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

#202

Post by tialaramex »

trulyrandom wrote: post #101
JackRabbitSlim wrote: post #99

Earlier quoted context omitted.

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…

TLS supports ECC certificates, so any web client using crypt32 to verify those is affected. That includes web browsers and lots of other types of services, so it's not primarily code signed executables. Does Firefox still use NSS when using the Windows Certificate Store for the source of trusted root certs? What about Chrome? You're right that RSA certificates are unaffected. There's no such thing as AES certificates…

> Does Firefox still use NSS when using the Windows Certificate Store for the source of trusted root certs?

Yes. When enabled this feature in Firefox just effectively copies certificates from one of the Windows trust stores but continues to use its own (NSS) logic for trust decisions. Note also that Firefox's config switch only looks at your local changes - a corporate CA, a MITM proxy on a dev's workstation, something like that. Firefox continues to rely on Mozilla's judgement not Microsoft's for global trust policy.

> What about Chrome?

Chrome is probably affected. Chrome uses the platform (in this case crypt32.dll) trust decisions and then layers on additional rules from Google, such as the requirement for proof of CT logging. So unless an additional rule is blocking the weird curves they'll pass on Chrome on Windows.

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

#203

Post by quotemstr »

Natanael_L wrote: post #193
quotemstr wrote: post #165

Earlier quoted context omitted.

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

We don't need the ability to switch to new algorithms as much as we need the ability to ditch old ones. Agility in cryptography only needs to mean the ability to deprecate what's broken. We're still going to see newer and more robust algorithms implemented in new software and protocol versions anyway. What we need is 1 or 2 strong cipher suites and exactly zero weak ones, not 10 strong ones and 5 weak ones.

How is that not cryptographic agility? Which cipher suites to support is a question separate from whether the cryptography should be runtime configurable at all.

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

#204

Post by [deleted] »

richardwhiuk wrote: post #40
Uptrenda wrote: post #22

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

"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

[deleted]

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

#206

Post by pjmlp »

roblabla wrote: post #200
pjmlp wrote: post #198

Earlier quoted context omitted.

> They need to stop only thinking in the ways OGL/D3D taught them to think, and need to also think like a driver developer, or possibly even a compiler developer. Which is exactly the opposite than anyone that wants to draw something wants to think about. Also Vulkan is on its merry path to have endless list of extensions, so it will eventually match OpenGL's complexity about what code paths to take, with the require…

Vulkan was never meant to be directly used by people who “just want to draw stuff”. It was meant to give engine developers the tools required to squeeze more performance out of the GPUs. This is a case of working as designed. The people trying to directly use Vulkan in their games without any middleware layer are just generally wrong here. Regarding extensions, this is just what happens when you specify something tha…

It would help if Khronos would promote an API for people who “just want to draw stuff”, given that OpenGL 5.0 will never happen most likely and those people don't want to be stuck with OpenGL 4.6 forever.

That is not what everyone does, because Vulkan gets new extensions updates almost every week.

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

#207

Post by loup-vaillant »

baby wrote: post #127
loup-vaillant wrote: post #117

Earlier quoted context omitted.

> If we can't even get crypto libraries right Signature verification is one of the hardest things to get right. One reason is, they're harder to test: when you encrypt or hash something, you have a whole bunch of bits you can check against test vectors. With signature verifications, you only have one bit: it's a match, or it's a fail. Moreover, it's very easy to forget to check something (here, that we are using the…

That’s an interesting assessment. Rogaway just gave a talk at RWC about APIs for secret splitting schemes. IIRC he said that the API needed to be closer to what symmetric crypto was. But from the diagram it seemed like you were obtaining some associated data back to check that the secret was correct (not sure if this would work/is relevant with more recent DKG schemes). A signature verification returning an actual AD…

EdDSA can have something close. Long story short, an EdDSA signature has two parts, often called "R" and "s". Verification works by producing a number using the public key and "s", then checking that this number is the same as "R". There are basically 3 steps:

  1. h_ram
Steps 1 and 3 are straightforward (the hash and the constant time comparison are almost always implemented in dedicated routines, tested separately). Step 2 is the most dangerous (that's where the elliptic curve magic happens).

EdDSA Implementations would be easier to check against one another if they all exposed step 2 as part of the public API. Bonus points if step 2 can handle invalid inputs (low order point, point on the twist...) in a standard manner. I haven't seen such a thing though, probably because end users never need a separate step 2.

Still, I can already envision the benefits. I'll probably use it myself.

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

#208

Post by loup-vaillant »

pjmlp wrote: post #206
roblabla wrote: post #200

Earlier quoted context omitted.

Vulkan was never meant to be directly used by people who “just want to draw stuff”. It was meant to give engine developers the tools required to squeeze more performance out of the GPUs. This is a case of working as designed. The people trying to directly use Vulkan in their games without any middleware layer are just generally wrong here. Regarding extensions, this is just what happens when you specify something tha…

It would help if Khronos would promote an API for people who “just want to draw stuff”, given that OpenGL 5.0 will never happen most likely and those people don't want to be stuck with OpenGL 4.6 forever. That is not what everyone does, because Vulkan gets new extensions updates almost every week.

> It would help if Khronos would promote an API for people who “just want to draw stuff”

Would it?

What you really want is a stable API to talk to the hardware. It doesn't really matter if the API is nigh unusable, as long as it is stable. Only when such stability is reached, can we reliably build stuff on top of it. Including a "just draw stuff" engine.

We could for instance re-implement Flash on top of Vulkan. Such a thing wouldn't need a standard body to get done and be usable by a wide range of people. (Though in this particular case, we'd likely have some standard body involved anyway, since there's already so much Flash code out there.)

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

#209

Post by ASN1 »

hannob wrote: post #178
Natanael_L wrote: post #177

Earlier quoted context omitted.

From what I read, x.509 allows the signer to specify the curve parameters along with the signature. And yes, the bug here would be that Windows accepted parameters B without confirming they match A, it only checked that the public key was the same. So you have official and trusted root / intermediate cert C1 which contains pubkey 1 and parameters A, which uses privkey 1 (secret obviously). When signing it doesn't usu…

That would make the attack plausible, but I wonder where these parameters are in practice. I tried creating a cert with custom curve parameters here: http://dpaste.com/1Q2MYWF It seems the parameter block is all part of "Subject Public Key Info". The signature is just a binary blob at the bottom. But openssl doesn't really break that down, does this signature have its internal encoding that allows supplying additiona…

Try pasting your cert into https://lapo.it/asn1js/

You can see all the parts in the blob:

        OBJECT IDENTIFIER 1.2.840.10045.2.1 ecPublicKey (ANSI X9.62 public key type)
        SEQUENCE (6 elem)
          INTEGER 1
          SEQUENCE (2 elem)
            OBJECT IDENTIFIER 1.2.840.10045.1.1 prime-field (ANSI X9.62 field type)
            INTEGER (256 bit) 1157920892373161954235709850086879078532699846656405640394575840079088…
          SEQUENCE (2 elem)
            OCTET STRING (32 byte) 0000000000000000000000000000000000000000000000000000000000000000
            OCTET STRING (32 byte) 0000000000000000000000000000000000000000000000000000000000000007
          OCTET STRING (65 byte) 0479BE667EF9DCBBAC55A06295CE870B07029BFCDB2DCE28D959F2815B16F81798483A…
          INTEGER (256 bit) 1157920892373161954235709850086879078528375642790749043826051631415181…
          INTEGER 1
This will help you understand the ASN.1 encoding of a cert: http://luca.ntop.org/Teaching/Appunti/asn1.html

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

#210

Post by pjmlp »

loup-vaillant wrote: post #208
pjmlp wrote: post #206

Earlier quoted context omitted.

It would help if Khronos would promote an API for people who “just want to draw stuff”, given that OpenGL 5.0 will never happen most likely and those people don't want to be stuck with OpenGL 4.6 forever. That is not what everyone does, because Vulkan gets new extensions updates almost every week.

> It would help if Khronos would promote an API for people who “just want to draw stuff” Would it? What you really want is a stable API to talk to the hardware. It doesn't really matter if the API is nigh unusable, as long as it is stable . Only when such stability is reached, can we reliably build stuff on top of it. Including a "just draw stuff" engine. We could for instance re-implement Flash on top of Vulkan. Suc…

So where do OpenGL developers move to, when 4.6 moves into "this legacy thing we would like to drop"?
Post reply on HN