Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

All of Oculus’s Rift headsets have stopped working due to an expired certificate

techcrunch.com

Post reply on HN
Print view View original

131–140 of 390 posts

Re: All of Oculus’s Rift headsets have stopped working due to an expired certificate

#131

Post by wtallis »

MertsA wrote: post #115
tedunangst wrote: post #73

Earlier quoted context omitted.

But that's only relevant/necessary to check at install time. Attackers aren't banking the drivers that I've already installed last year.

Checking at install time is effectively useless. The whole point of running signed code is that you can't just load some rootkit. Secure Boot only loads a signed bootloader which only loads a signed kernel which only loads signed kernel modules. You can't do what you're suggesting without fundamentally breaking this chain of trust. What's to stop a rootkit from just spoofing that it was installed months ago?

> What's to stop a rootkit from just spoofing that it was installed months ago?

The fact that if a rootkit is in a position to performing that spoofing, it doesn't need to, because it already has the power to make arbitrary modifications to the system image.

Re: All of Oculus’s Rift headsets have stopped working due to an expired certificate

#132

Post by wtallis »

mulmen wrote: post #118
wtallis wrote: post #94

Earlier quoted context omitted.

> Seems like a useful feature to be able to mark drivers as compromised. Putting expiration dates on non-malicious drivers is not a particularly effective way to protect against malicious drivers.

> There's no reason to re-verify the signature every time the driver is used. I was replying to this part of your comment. It does seem worthwhile to validate the signature of the driver every time the driver is used if that check would reveal when a certificate has been revoked for having been compromised. Agreed that the expiration time is not particularly useful for this purpose.

> It does seem worthwhile to validate the signature of the driver every time the driver is used if that check would reveal when a certificate has been revoked for having been compromised.

It would be much more efficient to scan the list of installed drivers every time a certificate revocation list is updated, because certificates are revoked much less often than operating systems are booted.

And there's nothing gained by just checking timestamps if you don't have a new certificate revocation list. If the driver is already installed and was trusted and running yesterday, you gain no security by deciding to not load and run that driver today, unless overnight you acquired new information that the driver is insecure or malicious. The ticking of a clock does not convey any such information.

Re: All of Oculus’s Rift headsets have stopped working due to an expired certificate

#133

Post by slededit »

wtallis wrote: post #129
slededit wrote: post #114

Earlier quoted context omitted.

Then you would need an internet connection just to install a driver. It would make getting your network driver installed pretty difficult. You could look at the system clock but that was not designed to be secure for this purpose.

> Then you would need an internet connection just to install a driver. If you think I'm proposing any changes to how drivers are installed, then you have misread me. I'm proposing a change to how already-installed drivers are handled: absent any new information, the code that was trusted yesterday should be trusted today, and be allowed to keep running.

Imagine a scenario where a driver is installed during a network outage and with an incorrect clock. Because you need to be able to install a network driver the system will allow this security flaw. However when the system knows better its reasonable to limit the damage by stopping the driver.

You could say that any damage has already been done which is most likely true. But I can't fault them from mitigating it as much as possible.

I suppose you could modify the system to get external attestation of the time while the driver is installed and use that as a sticky bit - but its a big complication and its much better if the driver is securely timestamped in the first place.

Re: All of Oculus’s Rift headsets have stopped working due to an expired certificate

#134

Post by gambler »

lunch wrote: post #126

A driver signed with any certificate that expires after July 29th, 2015, without time stamping, will work on Windows 10 until the certificate expires. https://docs.microsoft.com/en-us/windows-hardware/drivers/da...

What a horrible design decision. Instead of making a system that simply works or doesn't work Microsoft allowed everyone to produce apps which break at random times in the future. It's one of those "what could possibly go wrong?" cases.

Re: All of Oculus’s Rift headsets have stopped working due to an expired certificate

#136

Post by dannyw »

MertsA wrote: post #115
tedunangst wrote: post #73

Earlier quoted context omitted.

But that's only relevant/necessary to check at install time. Attackers aren't banking the drivers that I've already installed last year.

Checking at install time is effectively useless. The whole point of running signed code is that you can't just load some rootkit. Secure Boot only loads a signed bootloader which only loads a signed kernel which only loads signed kernel modules. You can't do what you're suggesting without fundamentally breaking this chain of trust. What's to stop a rootkit from just spoofing that it was installed months ago?

The signed kernel keeps track of when it first has seen a certificate. That is signed by a kernel, so a rootkit can’t spoof unless the system is already compromised.

Re: All of Oculus’s Rift headsets have stopped working due to an expired certificate

#137

Post by adrianratnapala »

andrewmcwatters wrote: post #96
maxander wrote: post #48

One wonders if we've made technology unnecessarily complicated. In order to build something like the Oculus Rift, they obviously needed expertise in hardware design, optics, display technology, manufacturing, user interface design, etc etc. Also, they apparently needed expertise in managing the ins-and-outs of the Windows driver security system. Adding one more subject to their already crowded curriculum wasn't very…

I was just reading something here about Cairo and how it's easy to fall into slow code paths with it, and if you happened across falling into a slow code path, somewhere along the line, "you fucked up." When I read the comment I was immediately flabbergasted: no, someone else fucked up. It's not my fault someone wrote software that sets up undocumented traps for me to fall into. Or provided three ways to do something…

The problem in this case is much deeper than their fault / your fault. The problem is that in this industry we do (have to?) lean too much on the power of abstraction.

Whether you are writing SQL or graphics code you are constantly told "just express what you want to express directly, and the system is smart enough to do things as efficiently as possible".

But that might not be very efficient at all. The people who write "the system" have to write software that does specific things in specific situations and there will be endless cases which cannot be dealt with efficiently. And the more the interface hides the implementation, the less likely it is that those cases will be obvious.

Re: All of Oculus’s Rift headsets have stopped working due to an expired certificate

#138

Post by robmaister »

kakarot wrote: post #31

Well, that explains why my Oculus wasn't working tonight. I hope this ends up being as easy to fix as downloading a new binary.

At the core of the issue, yeah, they just need to publish the same driver with a different signature.

It looks like their auto-updater used the same cert though, so they can't distribute it as a normal update. They're probably figuring out the least sketchy/most automated way to distribute it right now.

When this is all said and done, there will be a handful of people who will never, ever forget to use the /t flag in signtool.

Re: All of Oculus’s Rift headsets have stopped working due to an expired certificate

#139

Post by wtallis »

slededit wrote: post #133
wtallis wrote: post #129

Earlier quoted context omitted.

> Then you would need an internet connection just to install a driver. If you think I'm proposing any changes to how drivers are installed, then you have misread me. I'm proposing a change to how already-installed drivers are handled: absent any new information, the code that was trusted yesterday should be trusted today, and be allowed to keep running.

Imagine a scenario where a driver is installed during a network outage and with an incorrect clock. Because you need to be able to install a network driver the system will allow this security flaw. However when the system knows better its reasonable to limit the damage by stopping the driver. You could say that any damage has already been done which is most likely true. But I can't fault them from mitigating it as mu…

> Because you need to be able to install a network driver the system will allow this security flaw. However when the system knows better its reasonable to limit the damage by stopping the driver.

The only way that the system "knows better" is by acquiring something like a certificate revocation list. The system does not know whether it was powered down for five minutes while the network outage was fixed, or for five years. When the system is powered back on with a working internet connection, it does not have any reliable way to tell whether the offline installation of the network driver occurred prior to the expiration, or after the expiration with a properly backdated driver and backdated system clock. There is no way to justify suddenly de-trusting a driver that's already been running simply by observing that you're in the future.

Re: All of Oculus’s Rift headsets have stopped working due to an expired certificate

#140

Post by Someone1234 »

r1ch wrote: post #23

This is not how Windows code signing is supposed to work. Normally you'd get a countersignature from a timestamp server so that the verification process can prove that the certificate was valid at the time of signing. It would appear that Oculus signed their binaries without using a timestamp server, so without a way to verify when signing happened they become invalid as soon as the cert expires.

If anyone is interested in this topic this article goes into more detail:

https://msdn.microsoft.com/en-us/library/windows/desktop/bb9...

Post reply on HN