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

111–120 of 235 posts

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

#111

Post by Havoc »

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…

I like NSA being more active, but the concept of trusting NSA on crypto is just never gonna happen. Their core mandate is being able to break it so the whole concept is a non-starter

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

#112

Post by mzs »

Bluecobra wrote: post #95
es56yhse6 wrote: post #68

Interesting 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: https://cyber.dhs.gov/ed/20-02/

And that's for civilian systems. The only other time I can recall this happened was with the DNS vuln.

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

#113

Post by mzs »

alasdair_ wrote: post #104
mzs wrote: post #86

Earlier quoted context omitted.

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." h…

"random number generator"

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

#114

Post by gonnabezuul »

tptacek wrote: post #92
_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.

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…

Interesting. Were there any similar vulnerabilities in Windows XP's crypto libraries?

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

#115

Post by tptacek »

gonnabezuul wrote: post #114
tptacek wrote: post #92

Earlier quoted context omitted.

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…

Interesting. Were there any similar vulnerabilities in Windows XP's crypto libraries?

There have been crypto vulnerabilities in Windows libraries before, but not the e=3 vulnerability; CryptoAPI parsed RSA signatures back-to-front, and so sidestepped the issue.

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

#116

Post by chance_state »

cafxx wrote: post #103
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"

I think it's more like, "We find so many critical bugs, let's blow some of them for PR once we discover that adversaries are using them too."

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

#117

Post by loup-vaillant »

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

> 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 same base point). Other constructions, like EdDSA, are simpler, and verification requires a single equality check. Harder to botch.

And even then, implementers can be tempted to get clever, which requires extra care. I've personally been bitten by not verifying mathematical jargon, and mistakenly thought "birational equivalence" was complicated speak for "bijection". Almost, but not quite. This single oversight lead to a critical, easy to find, easy to exploit vulnerability.

We found out 15 months later, 1 full year after public release, by tinkering with the tests. A cryptographer would have found it in 5 minutes, but as far as I can tell, they're all very busy.

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

#118

Post by bodeadly »

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…

The problem is not with digital signatures. The problem is bad ECC certs used to generate digital signatures. So SMB is not affected. Code signed with one of these bad ECC certs is a concern. But considering that people install stuff that's not signed all the time, the primary issue is probably TLS MITM.

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

#119

Post by tptacek »

alasdair_ wrote: post #104
mzs wrote: post #86

Earlier quoted context omitted.

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." h…

"Dual Elliptic Curve" is an RNG, a PKRNG, that works by using a public key to encrypt its state, which is then directly revealed (as public key ciphertext) to callers (for instance: in the TLS random blob). The problem with PKRNGs has nothing to do with elliptic curves; you could design one with RSA as well. The problem is that for a given public key, there's also a private key, and if you have that private key you can "decrypt" the random value to reveal the RNG's state.

That's not a flawed curve that NSA pushed; it's a much more straightforward cryptographic backdoor.

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

#120

Post by tptacek »

Havoc wrote: post #111
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…

I like NSA being more active, but the concept of trusting NSA on crypto is just never gonna happen. Their core mandate is being able to break it so the whole concept is a non-starter

This kind of logic is attractive on message boards but makes little sense in the real world.

What NSA needs are NOBUS ("nobody but us") backdoors. Dual_EC is a NOBUS backdoor because it relies on public key encryption, using a key that presumably only NSA possesses. Any of NSA's adversaries, in Russia or Israel or China or France, would have to fundamentally break ECDLP crypto to exploit the Dual_EC backdoor themselves.

Weak curves are not NOBUS backdoors. The "secret" is a scientific discovery, and every industrialized country has the resources needed to fund new cryptographic discoveries (and, of course, the more widely used a piece of weak cryptography is, the more likely it is that people will discover its weaknesses). This is why Menezes and Koblitz ruled out secret weaknesses in the NIST P-curves, despite the fact that their generation relies on a random number that we have to trust NSA about being truly random: if there was a vulnerability in specific curves NSA could roll the dice to generate, it would be prevalent enough to have been discovered by now.

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.

Post reply on HN