> 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 actual bug yet other than which DLL it's in.

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 contiguous arbitrary chunk of data you get control over will be the public key, an RSA public key might be one kilobyte in size. So, conceivable but unlikely that you can squeeze a working exploit and payload in there.

An X.509 cert that isn't trusted in the Web PKI (ie hand rolled) is a better attack surface because you can write any amount of garbage without some busy body forbidding it, but now your problem is that a non-vulnerable client will see a problem immediately because it's untrusted which is weird. I don't look at the certificates on random web sites I visit... unless they don't work and then I might be curious.

I think code signing certs are a more likely vulnerability, unlike the Web PKI in practice this is down to Microsoft who have a very hands-off approach. I suspect you can get a lot more leeway to write crap into a cert for code signing and as a bonus it'll get seen by the vulnerable Windows PCs, because it's not as though Macs or Linux check the code signing certs on Windows software they can't run anyway.

But as you say we don't know anything, it could be a much more subtle but still dangerous bug.

For example suppose Microsoft's implementation of ECDHE misses a check on the parameters supplied by the other participant. This would make you vulnerable to invalid curve attacks when negotiating ECDHE. Of course a legitimate participant won't try to attack you, but you're doing ECDHE before you know the other participant's identity.

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.

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.

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

* client asks for cert

* you give it to them

* client tells you the page they want and their useragent

* if you think they're vulnerable based on what you've learned about them, you add <img src="https://vulnerable.subdomain/"> to the response.

Neat suggestion. Thanks! Agree we've moved well outside of tomorrow's likely actual vuln.

I'm also not convinced that the fields-allowed-by-CAs set is safe, especially when you consider the set of all browser-accepted CAs, it's historically been a fraught field.

Also with x.509 you have to decode the ASN.1 before you can even get to the signature, there have been historically been lots of vulnerabilities in ASN.1 parsers.

It would be a contradiction in terms. You can't validate the semantic content of a file before you've parsed it!

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 the cryptographic primitives are already all right there for you to use to authenticate the cert).

Google doing that would be a great way for everyone involved to spend a long time in jail.

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

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 (on servers and clients) and you'd never know it because the leak leaves no trace on the system and just looks like normal requests. Perfect exploit for spying. (And of course it's possible they had that exploit in their back pocket, but someone else reported it to M$, so now they're CYAing)

RCE in Windows Doesn't mean control over digital signature validation. But RCE in that particular API might mean both

This looks like it could be abused to lead to code execution.