Patch Critical Cryptographic Vulnerability in Microsoft Windows [pdf] • Hacker News Board

Re: Patch Critical Cryptographic Vulnerability in Microsoft Windows [pdf]

#211

Post by DiabloD3 » Wed, Jan 15, 2020, 5:03 PM UTC

pjmlp wrote: post #210

loup-vaillant wrote: post #208

Earlier quoted context omitted.

> It would help if Khronos would promote an API for people who “just want to draw stuff” Would it? What you really want is a stable API to talk to the hardware. It doesn't really matter if the API is nigh unusable, as long as it is stable . Only when such stability is reached, can we reliably build stuff on top of it. Including a "just draw stuff" engine. We could for instance re-implement Flash on top of Vulkan. Suc…

So where do OpenGL developers move to, when 4.6 moves into "this legacy thing we would like to drop"?

You implement OpenGL as a middleware that speaks Vulkan.

Basically, ANGLE it, but for desktop OpenGL instead of GLES.

As an aside, Google is adding a Vulkan backend for ANGLE, and Microsoft seems to be adding a DX12 (which is basically DXVulkan) backend (to match the DX11 backend they gave Google) at some point in the future.

So, GLES, in its entirety, is now a community supported, open source, Vulkan middleware. No reason why we can't do that with desktop GL too.

Re: Patch Critical Cryptographic Vulnerability in Microsoft Windows [pdf]

#212

Post by 0xff00ffee » Wed, Jan 15, 2020, 6:10 PM UTC

_nedR wrote: post #160

0xff00ffee wrote: post #150

Earlier quoted context omitted.

> just burn all the things and start over Wrap all of this with an "IN MY OPINION"... That would make things worse because we'd make the same mistakes again. I've been on many start over projects (Xeon Phi, for example, threw out the P4 pipeline and went back to the Pentium U/V). It doesn't work. You know what the most robust project I've worked on? The instruction decoder on Intel CPUs. The validation tests go back…

Yep : https://www.joelonsoftware.com/2000/04/06/things-you-should-...

Thank you for this, it's exactly what I'm getting at.

Re: Patch Critical Cryptographic Vulnerability in Microsoft Windows [pdf]

#213

Post by pjmlp » Wed, Jan 15, 2020, 6:14 PM UTC

DiabloD3 wrote: post #211

pjmlp wrote: post #210

Earlier quoted context omitted.

So where do OpenGL developers move to, when 4.6 moves into "this legacy thing we would like to drop"?

You implement OpenGL as a middleware that speaks Vulkan. Basically, ANGLE it, but for desktop OpenGL instead of GLES. As an aside, Google is adding a Vulkan backend for ANGLE, and Microsoft seems to be adding a DX12 (which is basically DXVulkan) backend (to match the DX11 backend they gave Google) at some point in the future. So, GLES, in its entirety, is now a community supported, open source, Vulkan middleware. No…

So 10 years from now those that don't want to be a mix of graphical developer, driver author and compiler designers, have to keep using a frozen API from 2018, without any access to whatever has changed on their computers during the next decade.

All because providing something like MetalKit or DirectXTK is too much to ask for to Khronos and LunarG.

Re: Patch Critical Cryptographic Vulnerability in Microsoft Windows [pdf]

#214

Post by inimino » Wed, Jan 15, 2020, 6:35 PM UTC

sillysaurusx wrote: post #109

Uptrenda wrote: post #72

Earlier quoted context omitted.

It's scarier the more you think about it because digital sigs are the first place you look for most "secure protocols." I think reading between the lines there are multiple attack scenarios: - Fake windows updates - The notorious SMB protocol -- "The Server Message Block (SMB) protocol provides the basis for file and print sharing and many other networking operations, such as remote Windows administration. To prevent…

Love the shock. Take a job as a pentester (or don’t) and you’ll look at your list, nod, and say “Yes. This is normal.” It’s normal to be broken. That’s why to do pentests on every piece of security infrastructure. The hypothesis that systems like this ought to be secure is empirically false. I am trying to shake the shock out of you, because your surprise = my surprise before being a pentester. But the job forces you…

> There is zero chance software would end up impenetrable under those conditions.

Not when it is so impenetrably complex that there are always hidden errors. The only secure software is simple enough that a single human mind can comprehend it and verify correctness, and as an entire industry we have moved away from that entirely.

Re: Patch Critical Cryptographic Vulnerability in Microsoft Windows [pdf]

#215

Post by DiabloD3 » Wed, Jan 15, 2020, 6:49 PM UTC

pjmlp wrote: post #213

DiabloD3 wrote: post #211

Earlier quoted context omitted.

You implement OpenGL as a middleware that speaks Vulkan. Basically, ANGLE it, but for desktop OpenGL instead of GLES. As an aside, Google is adding a Vulkan backend for ANGLE, and Microsoft seems to be adding a DX12 (which is basically DXVulkan) backend (to match the DX11 backend they gave Google) at some point in the future. So, GLES, in its entirety, is now a community supported, open source, Vulkan middleware. No…

So 10 years from now those that don't want to be a mix of graphical developer, driver author and compiler designers, have to keep using a frozen API from 2018, without any access to whatever has changed on their computers during the next decade. All because providing something like MetalKit or DirectXTK is too much to ask for to Khronos and LunarG.

But should it change? There are issues where updating OpenGL support in drivers broke earlier apps due to accidental changes in how existing features were implemented.

Vulkan and DX12 are far less likely to break existing apps i the future due to far fewer core features.

It makes no sense to have what is essentially an entire legacy middleware in the driver when it no longer represents modern hardware.

Unlike GLES, OpenGL basically can never deprecate features, and D3D9 support will never, truly, die. It's a lot easier to just package a universal shim into existing legacy apps than it is to keep mangling drivers over the issue.

Re: Patch Critical Cryptographic Vulnerability in Microsoft Windows [pdf]

#216

Post by tptacek » Wed, Jan 15, 2020, 6:54 PM UTC

tialaramex wrote: post #199

tptacek wrote: post #164

Earlier quoted context omitted.

Who on earth has a corporate internal CA that issues certificates signed on non-standard curves? Who would ever do that? It's not like you're just a couple parameters away from Curve25519; a serious alternative curve will always come with alternative curve code .

In the scenario I'm describing specifiedCurve is NOT being used to sign with non-standard curves, it's being used to sign with the standard curves but expressed using specifiedCurve anyway. As a crypto/ security person your instinct is to say "No" because if something is more complicated but adds no apparent benefit that's a problem. That's why PKIX says "No" here, and it's why Mozilla policy says "No" here. But for…

I get all that, but I'm asking: why would anyone ever do this? What conceivable benefit could there be to it?

Re: Patch Critical Cryptographic Vulnerability in Microsoft Windows [pdf]

#217

Post by smolder » Wed, Jan 15, 2020, 7:05 PM UTC

loup-vaillant wrote: post #181

0xff00ffee wrote: post #150

Earlier quoted context omitted.

> just burn all the things and start over Wrap all of this with an "IN MY OPINION"... That would make things worse because we'd make the same mistakes again. I've been on many start over projects (Xeon Phi, for example, threw out the P4 pipeline and went back to the Pentium U/V). It doesn't work. You know what the most robust project I've worked on? The instruction decoder on Intel CPUs. The validation tests go back…

> You make progress by building on top and fixing your mistakes because there literally IS NO OTHER WAY. As long as you are talking about knowledge, not artefacts. There is indeed no choice but accrete, organise, and correct knowledge over time, because anything you forget is something you might get wrong all over again. Artefacts are different. It often makes sense to rebuild some of them from scratch, using more re…

Perhaps wireguard VPN as a low-cruft replacement for openvpn is a good illustration of this.

Re: Patch Critical Cryptographic Vulnerability in Microsoft Windows [pdf]

#218

Post by shinigami » Wed, Jan 15, 2020, 7:12 PM UTC

hannob wrote: post #178

Natanael_L wrote: post #177

Earlier quoted context omitted.

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…

That would make the attack plausible, but I wonder where these parameters are in practice. 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 additiona…

Subject Public Key Info is just an Algorithm Identifier and the public key. The Algorithm Identifier is an OID and the parameters (ECParameters when using EC keys). It's these parameters that can contain the custom EC domain parameters.

The certificate signature is preceded by another Algorithm Identifier that specifies the signature algorithm (and the parameters), and so it seems that Microsoft is using this value instead of the parameters in the signer certificate Subject Public Key Info?

Re: Patch Critical Cryptographic Vulnerability in Microsoft Windows [pdf]

#219

Post by pjmlp » Wed, Jan 15, 2020, 7:13 PM UTC

DiabloD3 wrote: post #215

pjmlp wrote: post #213

Earlier quoted context omitted.

So 10 years from now those that don't want to be a mix of graphical developer, driver author and compiler designers, have to keep using a frozen API from 2018, without any access to whatever has changed on their computers during the next decade. All because providing something like MetalKit or DirectXTK is too much to ask for to Khronos and LunarG.

But should it change? There are issues where updating OpenGL support in drivers broke earlier apps due to accidental changes in how existing features were implemented. Vulkan and DX12 are far less likely to break existing apps i the future due to far fewer core features. It makes no sense to have what is essentially an entire legacy middleware in the driver when it no longer represents modern hardware. Unlike GLES, O…

> It makes no sense to have what is essentially an entire legacy middleware in the driver when it no longer represents modern hardware.

Exactly, but it is the only API that Khronos is offering for those that don't want to be Vulkan experts.

Which leaves middleware engines, something totally unrelated to Khronos APIs, as the only future proof path for accessing GPU features on modern hardware.

As for drivers breaking down, the main reason why Vulkan is now compulsory on Android as of version 10, is because while it was optional, the few OEMs that bothered to support it did a very lousy job, so Google hopes by making it compulsory and part of Android CTS, the situation will improve.

Re: Patch Critical Cryptographic Vulnerability in Microsoft Windows [pdf]

#220

Post by benth » Wed, Jan 15, 2020, 7:17 PM UTC

ASN1 wrote: post #209

hannob wrote: post #178

Earlier quoted context omitted.

That would make the attack plausible, but I wonder where these parameters are in practice. 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 additiona…

Try pasting your cert into https://lapo.it/asn1js/ You can see all the parts in the blob: OBJECT IDENTIFIER 1.2.840.10045.2.1 ecPublicKey (ANSI X9.62 public key type) SEQUENCE (6 elem) INTEGER 1 SEQUENCE (2 elem) OBJECT IDENTIFIER 1.2.840.10045.1.1 prime-field (ANSI X9.62 field type) INTEGER (256 bit) 1157920892373161954235709850086879078532699846656405640394575840079088… SEQUENCE (2 elem) OCTET STRING (32 byte) 0000…

The parent comment is wondering about the structure of the signature and if different curve parameters can be specified for it. How can explicit curve parameters be specified in an ECDSA signature? ecdsaWithSHA256, at least, is simply two bigints. There's no spot for specifying explicit parameters.