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

101–110 of 235 posts

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

#101

Post by trulyrandom »

JackRabbitSlim wrote: post #99
trulyrandom wrote: post #73

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

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

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

#102

Post by rasz »

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…

>The old crypto API -didn't- check that certificates were signed from a fixed set of valid parameters. It would just check for sig validity allowing for spoofing of the cert.

This sounds exactly how pdf signatures were attacked and successfully defeated https://media.ccc.de/v/36c3-10832-how_to_break_pdfs https://www.youtube.com/watch?v=k8FIDGmmYvs

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

#103

Post by cafxx »

kornholi wrote: post #3

From Krebs tweets: The NSA's Neuberger said this wasn't the first vulnerability the agency has reported to Microsoft, but it was the first one for which they accepted credit/attribution when MS asked. Sources say this disclosure from NSA is planned to be the first of many as part of a new initiative at NSA dubbed "Turn a New Leaf," aimed at making more of the agency's vulnerability research available to major softwar…

> Sources say this disclosure from NSA is planned to be the first of many as part of a new initiative at NSA dubbed "Turn a New Leaf," aimed at making more of the agency's vulnerability research available to major software vendors and ultimately to the public.

Sounds like "we find so many critical bugs... we don't need all of them to achieve our goals, so let's blow some of them for PR"

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

#104

Post by alasdair_ »

mzs wrote: post #86
blaser-waffle wrote: post #75

Earlier quoted context omitted.

Didn't the FBI or NSA push for flawed Elliptical Curve Crypto in the past? Could be the knew about it for a while and had milked it hard until they caught someone else using it. Or like the parent said, previously discovered flaws meant that someone might catch this one, too.

There is no evidence that US push flawed curves.

>There is no evidence that US push flawed curves.

"Reuters reported in December that the NSA had paid RSA $10 million to make a now-discredited cryptography system the default in software used by a wide range of Internet and computer security programs. The system, called Dual Elliptic Curve, was a random number generator, but it had a deliberate flaw - or “back door” - that allowed the NSA to crack the encryption."

https://www.reuters.com/article/us-usa-security-nsa-rsa/excl...

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

#105

Post by mzs »

> https://twitter.com/randomoracle/status/1217198437281804290

Some speculation on CVE-2020-0601.

Earlier version of Windows cryptography API only supported a handful of elliptic curves from NIST suite-B. It could not handle say an arbitrary prime-curve in Weierstrass form with user defined parameters

…

While it could not grok arbitrary curves, Windows API made an attempt to recognize when a curve with explicit user-defined parameters was in fact identical to "built-in" curve that is supported

It appears that mapping was "lazy:" it failed to check that all curve parameters are identical to the known curve.

In particular, switching the generator point results in a different curve in which an attacker can forge signatures that match a victim public key

> https://twitter.com/esizkur/status/1217176214047219713

It looks like this may be a caching issue: There's a CCertObjectCache class in crypt32.dll. In the latest release its member function FindKnownStoreFlags (called from its constructor) started checking the public key and parameters

> https://twitter.com/thracky/status/1217175743316348929

ChainComparePublicKeyParametersAndBytes used to just be a memcmp before the patch. Same with any calls to IsRootEntryMatch. Both new functions.

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

#106

Post by Stratoscope »

mastazi wrote: post #74
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…

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

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

#107

Post by munchbunny »

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

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

Say we stop using X509 certificates. We will continue to use signing to cryptographically bind claims, and we will still use PKI-like structures to attest trustworthiness, so we are still vulnerable to the same approaches of attacks even if we don’t use certificates.

We have actually learned a few things, such as that cryptographic agility seems to cause more issues than the problems it solves, so the field is improving in important ways, but if it’s not a key matching weakness, it’s going to be some Unicode encoding BS or some other critical but not validated data somewhere else, or... (because this is a real in the wild problem) using phone numbers to generate cryptographic keys for coin wallets.

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

#108

Post by tptacek »

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…

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 talking about certificates that allow you to embed what is in effect your own cryptographic algorithm to interpret the certificate under!

This is a rare instance where I'm happy to concede that closed source allowed a terrible bug to survive far longer than it would have if nobody needed to break out a copy of Ghidra to read the code that validated elliptic curve signatures.

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

#109

Post by sillysaurusx »

Uptrenda wrote: post #72
richardwhiuk wrote: post #40

Earlier 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

It's scarier the more you think about it because digital sigs are the first place you look for most "secure protocols." I think reading between the lines there are multiple attack scenarios: - Fake windows updates - The notorious SMB protocol -- "The Server Message Block (SMB) protocol provides the basis for file and print sharing and many other networking operations, such as remote Windows administration. To prevent…

Love the shock.

Take a job as a pentester (or don’t) and you’ll look at your list, nod, and say “Yes. This is normal.”

It’s normal to be broken. That’s why to do pentests on every piece of security infrastructure.

The hypothesis that systems like this ought to be secure is empirically false. I am trying to shake the shock out of you, because your surprise = my surprise before being a pentester. But the job forces you to come to terms with the fact that everyone, everywhere, is broken, always, and this is neither surprising nor (and you’ll hate this part) a big deal.

Bug is fixed. Life goes on. Yes, of course the infrastructure could have been attacked from any time between “forever ago” and that fix. Ask yourself: why is this surprising to me? And carefully examine the assumptions with which you want to say “because it’s their job to make it secure...”

To be clear, I wish the world were different. But I wish we’d take a hard look at reality and the history of vulnerabilities. Stop thinking things are secure just because the label says “secure”. People devote their entire existence to seeking out and exploiting the tiniest imperfections, sometimes for no reason other than because it’s fun to do so. There is zero chance software would end up impenetrable under those conditions.

Hell, even Tarsnap screwed up once, and Colin is pretty much cryptographically-signed Jesus. So if someone as smart and dedicated as him can make these mistakes, what hope have we? Especially when “we” consists of a large number of programmers working together, and all the complexities that entails?

Post reply on HN