171–180 of 235 posts
At least this only affects Windows 10 (as far as I can tell)
Windows 7 reached EOL today so they may leave it as is if it is affected.
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'm assuming there will never be an official proof of concept release, so how long do you all think it will be before we see widely available exploit code and fake certificates out in the wild?
> Saleem Rashid worked out a POC for this on Slack in something like 45 minutes today
So I would be amazed if there were not some malicious certificates out there already.
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…
So the mitigation would be to add a check that the generator point in (for example) a CertificateVerify message is the one in the p256 spec (or otherwise the one on the cert, I’m not deep enough to know where it usually lives)?
This stems from a time where people thought maximum flexibility in cryptography is a good idea. It's not.
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…
From what I understand we can put custom parameters into a certificate, but the parameters come with the key, not the signature. So we have
CA cert + key A + parameters A
signs
My cert + key B + parameters B + forged signature from A
Now we can only mount this attack if we can somehow control a part of the parameters (the basepoint) that is used to verify the forged signature. Is the bug that windows is using parameters B to verify signature from A? Or am I missing something and there is another way to supply parameters with a signature?
Could someone clarify: does this allow the creation of fake certificates that are accepted as authentic by any crypto library? Or rather, does it treat such faked certificates as authentic itself?
> Could someone clarify: does this allow the creation of fake certificates that are accepted as authentic by any crypto library? No, only the Windows native one. For instance, Firefox (which uses NSS) would be safe.
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…
So this explains the math and crypto part, but how does that tie into X.509 and certificates? From what I understand we can put custom parameters into a certificate, but the parameters come with the key, not the signature. So we have CA cert + key A + parameters A signs My cert + key B + parameters B + forged signature from A Now we can only mount this attack if we can somehow control a part of the parameters (the ba…
And yes, the bug here would be that Windows accepted parameters B without confirming they match A, it only checked that the public key was the same.
So you have official and trusted root / intermediate cert C1 which contains pubkey 1 and parameters A, which uses privkey 1 (secret obviously). When signing it doesn't usually specify parameters (just gets it from the trusted cert), the leaf certificate just contain the reference to the trusted cert and its public key and of course also contains the actual signature.
In the attack you reuse pubkey 1 but create parameters B and associated privkey 2, and using that you create a leaf cert that contain both the same references that an official signature would contain - except you also specify parameters B, and then supply the signature that validates only under parameters B, and then Windows accepts both the parameters and the signature.
Earlier quoted context omitted.
So this explains the math and crypto part, but how does that tie into X.509 and certificates? From what I understand we can put custom parameters into a certificate, but the parameters come with the key, not the signature. So we have CA cert + key A + parameters A signs My cert + key B + parameters B + forged signature from A Now we can only mount this attack if we can somehow control a part of the parameters (the ba…
From what I read, x.509 allows the signer to specify the curve parameters along with the signature. And yes, the bug here would be that Windows accepted parameters B without confirming they match A, it only checked that the public key was the same. So you have official and trusted root / intermediate cert C1 which contains pubkey 1 and parameters A, which uses privkey 1 (secret obviously). When signing it doesn't usu…
I tried creating a cert with custom curve parameters here: http://dpaste.com/1Q2MYWF
It seems the parameter block is all part of "Subject Public Key Info". The signature is just a binary blob at the bottom. But openssl doesn't really break that down, does this signature have its internal encoding that allows supplying additional parameters?
And if that's the case: How does that make any sense? It sounds like just asking for trouble. (I mean... there never can be a situation where the parameters of the signature do not match the parameters of the key.)
Earlier quoted context omitted.
Yep : https://www.joelonsoftware.com/2000/04/06/things-you-should-...
> April 6, 2000 Wow. That goes waaaaaaay back. It’s crazy to think that 1980 was to him at the time as 2000 is to us _right now_.
Earlier quoted context omitted.
The pseudonymous but well-connected 'swiftonsecurity' twitter account reports on background that 'RCE' chatter about this particular vulnerability does indeed relate to compromised software update channels. (Not just AuthentiCode, but also MITM on, say, connections to the npm package server.) See https://twitter.com/SwiftOnSecurity/status/12171594348808478... That said, this same patch set also has a separate pre-aut…
> connections to the npm package server Doesn't npm use node.js for this, which uses openssl? > https://nodejs.org/api/tls.html#tls_tls_ssl Third party tools connecting to the npm server that use Window's TLS library would absolutely be affected though.