Cryptic Rumblings Ahead of First 2020 Patch Tuesday

Post by peterwwillis » Tue, Jan 14, 2020, 4:06 AM UTC

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…

Post by atxlurker » Tue, Jan 14, 2020, 4:32 AM UTC

peterwwillis wrote: post #51

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…

> Am I missing something or is there a way to turn a spoofed certificate into a single-click pwn? 1) if there's a bug in the crypto library that creates RCE 2) if a mitm delivers a payload to an application (browser/plugin/etc) and that causes RCE. The former might cause NSA to get its panties in a wad. But it might be much worse than RCE. It might be like Heartbleed, where it can leak key material and memory all day…

Post by ikeboy » Tue, Jan 14, 2020, 5:15 AM UTC

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.

Post by cjbprime » Tue, Jan 14, 2020, 6:06 AM UTC

atxlurker wrote: post #52

cjbprime wrote: post #49

Earlier quoted context omitted.

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.

I don’t think this is ultimately the vulnerability, but even without SNI, it’s arbitrary to dynamically link to a file, script, png, etc... hosted on a sub domain with the bad cert.

Post by ct520 » Tue, Jan 14, 2020, 6:59 AM UTC

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…