Re:Cryptic Rumblings Ahead of First 2020 Patch Tuesday
by tialaramex on Monday January 13, 2020 @10:34PM
(#22041597)
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
by ikeboy on Tuesday January 14, 2020 @12:15AM
(#22042054)
Just load a hidden image from a subdomain, silently fails if on an unaffected platform.
Re:Cryptic Rumblings Ahead of First 2020 Patch Tuesday
by Thorrez on Tuesday January 14, 2020 @01:19AM
(#22042327)
And you could also avoid even creating the iframe if the User Agent isn't Windows.
Re:Cryptic Rumblings Ahead of First 2020 Patch Tuesday
by cjbprime on Monday January 13, 2020 @10:39PM
(#22041621)
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
by atxlurker on Monday January 13, 2020 @11:30PM
(#22041861)
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.
Re:Cryptic Rumblings Ahead of First 2020 Patch Tuesday
by cjbprime on Tuesday January 14, 2020 @01:06AM
(#22042270)
Oh yeah! So it's like:
* 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.
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.