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

Cryptic Rumblings Ahead of First 2020 Patch Tuesday

krebsonsecurity.com

Post reply on HN
Print view View original

41–50 of 96 posts

Re: Cryptic Rumblings Ahead of First 2020 Patch Tuesday

#41

Post by DrJosiah »

AaronFriel wrote: post #2

Scary, but not an RCE so threat is limited. It would mean malicious actors could possible create spoofed signatures on malware or possibly websites (EV certificates?). Am I missing something or is there a way to turn a spoofed certificate into a single-click pwn? As I understand it, users would have to download a malicious payload or click a malicious URL to be exposed. Edit: People are asking why I assume it's not a…

My money is on it to disable support for sha1 in old products; maybe a bigger break than the prefix attack currently known.

Re: Cryptic Rumblings Ahead of First 2020 Patch Tuesday

#42

Post by taneq »

computator wrote: post #15

It's a shame that mathematically proving correctness of code, even for extremely important code , is never done. I wonder how many lines of code in crypt32.dll. Is it on the order of 7500 lines? If Microsoft spent a few man-years mathematically proving the correctness of that code, they could have the saved the world about 10,000 man-years. Windows has a user base of 1 billion[1]. A ballpark figure for proving the co…

"Beware of bugs in the above code; I have only proved it correct, not tried it." - Donald Knuth

Re: Cryptic Rumblings Ahead of First 2020 Patch Tuesday

#43

Post by cjbprime »

tialaramex wrote: post #39
cjbprime wrote: post #9

Earlier quoted context omitted.

Wait, how do you know it's not an RCE? Memory safety flaws in a DLL become RCE all the time. > is there a way to turn a spoofed certificate into a single-click pwn? e.g. The victim clicks on a link to go to your website, their machine wants to validate the TLS cert you sent it, it calls into crypt32.dll to do that, it corrupts memory while handling your attacking cert, pwn? We don't know enough (anything!) about the…

Certificates in the Web PKI (so they'd be trusted) aren't likely to be a good basis for an exploit. You aren't supposed to get to pick very much of the document in the Web PKI. Rules forbid CAs from letting you write nonsense you made up into most places - they themselves get slightly more opportunity but "Let's attack a windows zero day" doesn't feel like a good use of control over a trusted CA. The biggest contiguo…

> will see a problem immediately because it's untrusted which is weird

You might be right, but I don't think your version of "immediately" matches up with the reality of code. How many cert library function calls do you think happen before a TLS client is able to decide that there is no trusted path to the cert's authority and decide that it's "weird"?

Hundreds or thousands wouldn't surprise me -- you've got to parse a file format, follow links -- if the vulnerability's in one of those functions, then there's your exploit. You even have to go out to the filesystem, check whether the self-signed CA is installed in the OS trust store, which would make it trusted. It's really easy for me to imagine such a vuln somewhere in cert trust verification.

Re: Cryptic Rumblings Ahead of First 2020 Patch Tuesday

#44

Post by cjbprime »

thephyber wrote: post #31
r00fus wrote: post #22

Earlier quoted context omitted.

> If Microsoft spent a few man-years mathematically proving the correctness of that code, they could have the saved the world about 10,000 man-years. But how much more profitable could it have been? Is it possible Microsoft makes more money by not doing it? We cannot expect companies to behave in the greater population's best interest unless there is some reward/punishment structure in place. Enter regulation.

Lots of people in this thread are complaining that a formal proof is not reasonable and will not catch all classes of errors. I think r00fus is right to look at the profit motive of the software supplier. Microsoft would have been climbing a steep curve of diminishing returns for basically no extra revenue. Windows isn’t the monster revenue generator and in the server space it’s losing to free Operating Systems. We a…

There actually is regulation, though. As I understand it, in theory GDPR could now fine Microsoft 1% of revenue if they've behaved catastrophically negligently at keeping user secrets secure.

Re: Cryptic Rumblings Ahead of First 2020 Patch Tuesday

#45

Post by bitexploder »

blattimwind wrote: post #21
computator wrote: post #15

It's a shame that mathematically proving correctness of code, even for extremely important code , is never done. I wonder how many lines of code in crypt32.dll. Is it on the order of 7500 lines? If Microsoft spent a few man-years mathematically proving the correctness of that code, they could have the saved the world about 10,000 man-years. Windows has a user base of 1 billion[1]. A ballpark figure for proving the co…

> I wonder how many lines of code in crypt32.dll. Is it on the order of 7500 lines? If Microsoft spent a few man-years mathematically proving the correctness of that code, they could have the saved the world about 10,000 man-years. Crypt32 mostly concerns itself with X.509 certificates and I believe actually implements all that stuff (instead of delegating it elsewhere). I wouldn't be surprised if it contains conside…

X.509 and TLV is gnarly. So many edge cases. Then there are encoding formats and many other things. It’s 50kloc easy. The file size is like 500k. A lot happens in there for sure.

Re: Cryptic Rumblings Ahead of First 2020 Patch Tuesday

#46

Post by tialaramex »

cjbprime wrote: post #43
tialaramex wrote: post #39

Earlier quoted context omitted.

Certificates in the Web PKI (so they'd be trusted) aren't likely to be a good basis for an exploit. You aren't supposed to get to pick very much of the document in the Web PKI. Rules forbid CAs from letting you write nonsense you made up into most places - they themselves get slightly more opportunity but "Let's attack a windows zero day" doesn't feel like a good use of control over a trusted CA. The biggest contiguo…

> will see a problem immediately because it's untrusted which is weird You might be right, but I don't think your version of "immediately" matches up with the reality of code. How many cert library function calls do you think happen before a TLS client is able to decide that there is no trusted path to the cert's authority and decide that it's "weird"? Hundreds or thousands wouldn't surprise me -- you've got to parse…

I meant on unaffected platforms, say, Firefox on Linux. It'd be weird if I came to, say, Hacker News and now it had this untrusted cert (which is actually a worm attacking Windows PCs) instead of a normal one.

I agree that on an affected platform all bets are off, but deploying to a web server means you don't easily get to pick who your visitors are.

Re: Cryptic Rumblings Ahead of First 2020 Patch Tuesday

#47

Post by cjbprime »

bob1029 wrote: post #23
cjbprime wrote: post #9

Earlier quoted context omitted.

Wait, how do you know it's not an RCE? Memory safety flaws in a DLL become RCE all the time. > is there a way to turn a spoofed certificate into a single-click pwn? e.g. The victim clicks on a link to go to your website, their machine wants to validate the TLS cert you sent it, it calls into crypt32.dll to do that, it corrupts memory while handling your attacking cert, pwn? We don't know enough (anything!) about the…

This would be a terrifying outcome if certificate-based RCE. Imagine an actor like google running an intentionally-compromised TLS certificate on their web servers... perhaps even targeted at specific IP addresses or on certain schedules to avoid detection. Certificates are an excellent initiation vector too. Especially, if one wanted to intentionally present a backdoor like this for national security reasons (all of…

> Imagine an actor like google running an intentionally-compromised TLS certificate on their web servers... perhaps even targeted at specific IP addresses or on certain schedules to avoid detection.

For what it's worth, you should read about Certificate Transparency, it tries to protect against this sort of problem. Browsers only accept certs that can prove they've been submitted to a public log, which means that their existence isn't being selectively exposed to some users only.

(They mainly act as prevention against rogue certificate authorities rather than a rogue cert owner, though.)

Re: Cryptic Rumblings Ahead of First 2020 Patch Tuesday

#48

Post by rtpg »

mcguire wrote: post #36
AnimalMuppet wrote: post #29

Earlier quoted context omitted.

Define "proving correctness". Proving that it does what it's supposed to? You need a formal spec as the starting point for that; how do you prove that the formal spec correctly describes what the software's supposed to do? Proving that it has no bugs? That only works for the kinds of bugs covered by the proof. Your proof that it has no null pointer crashes tells us nothing about whether it has off-by-one errors. For…

One might hope you have a formal spec of a cryptographic library.

While proving code matches a spec is very helpful, it's only as helpful as the spec being "correct" from a "does what we want it to do" angle.

For example, you could do a bunch of spec proving on CPUs, but you wouldn't catch something like Spectre if your definition of correctness didn't include "no information leakage can happen through timings on branch prediction".

And even then! You need to have the right definition on that front!

Having specs and formally proven code helps to make sure your code isn't prone to a certain class of errors (just like bounds checking/lack of raw pointers prevents another class of errors), but it's not a magical catch-all. Especially if you are in a space like cryptography where you're trying to assert negatives (that end up being held up by assumptions around feasibility of certain things)

Re: Cryptic Rumblings Ahead of First 2020 Patch Tuesday

#49

Post by cjbprime »

tialaramex wrote: post #46
cjbprime wrote: post #43

Earlier quoted context omitted.

> will see a problem immediately because it's untrusted which is weird You might be right, but I don't think your version of "immediately" matches up with the reality of code. How many cert library function calls do you think happen before a TLS client is able to decide that there is no trusted path to the cert's authority and decide that it's "weird"? Hundreds or thousands wouldn't surprise me -- you've got to parse…

I meant on unaffected platforms, say, Firefox on Linux. It'd be weird if I came to, say, Hacker News and now it had this untrusted cert (which is actually a worm attacking Windows PCs) instead of a normal one. I agree that on an affected platform all bets are off, but deploying to a web server means you don't easily get to pick who your visitors are.

Oh yes, that's true. (Though now I wonder if cert negotiation can be dependent on useragent under SNI. It could certainly be dependent on TCP fingerprint characteristics.)

Agree with you that codesigning certs are a more likely problem space for this bug.

Re: Cryptic Rumblings Ahead of First 2020 Patch Tuesday

#50

Post by mcguire »

msla wrote: post #40
mcguire wrote: post #36

Earlier quoted context omitted.

One might hope you have a formal spec of a cryptographic library.

> One might hope you have a formal spec of a cryptographic library. Which would be a good first step, but wouldn't protect against timing attacks or Spectre-like hardware frailties. A solid start is better than nothing, but a false sense of security is worse than nothing.

Is crypt32 supposed to be secure against timing attacks?
Post reply on HN