All of Oculus’s Rift headsets have stopped working due to an expired certificate • Hacker News Board

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

#171

Post by JohnTHaller » Thu, Mar 08, 2018, 7:04 AM UTC

eksemplar wrote: post #159

lopmotr wrote: post #81

Earlier quoted context omitted.

Something like that. Certificates aren't supposed to stop working just because they've expired! That would destroy all abandoned or poorly maintained software within a couple of years. This problem is deeper than forgetting to update it. It should never have caused a failure in the first place. Just the fact that the device apparently can't function at all without the internet is a problem too.

> Certificates aren't supposed to stop working just because they've expired! That’s exactly how they are supposed to work. In the public sector we rely heavily on certificates for inter sector communication for instance, if certificates kept working despite being invalid it would put security at risk. You’re supposed to build your software with an enterprise certificate store in mind though, meaning you can auto rene…

Code signing certificates are different from website certificates. When you use a code signing certificate - when doing it right, anyway - you also loop in a timestamp server. That way, you're signing it with your currently valid certificate and a third party is proving it was signed at a time the certificate is valid. This is so that when your code signing certificate expires in a few months, the binary you signed while the certificate was valid can still be used. Without timestamp servers, you couldn't now go back and install an older version of Firefox, for instance, because the certificate it was signed with last year is now expired.

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

#172

Post by fsloth » Thu, Mar 08, 2018, 7:09 AM UTC

adrianratnapala wrote: post #137

andrewmcwatters wrote: post #96

Earlier quoted context omitted.

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 w…

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

That's just an excuse to stop mediocre engineers who would fiddle endlessly with pointless micro optimizations.

You very much need to understand the performance of your code if the product has performance requirements that fail unless you do.

I presume most coding is just crudding small strings from UI to database, where performance issues don't kick in, and hence it would be wastefull to care about them.

I've watched production builds to crawl to a halt and become sluggish as molasses because someone in the dev team was indoctrinated in this creed. (Many reasons, including a cartresian explosion in complexity due to some innocuous LINQ calls).

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

#173

Post by moefh » Thu, Mar 08, 2018, 7:09 AM UTC

cxseven wrote: post #161

Kikawala wrote: post #49

Earlier quoted context omitted.

By adding a timestamp to digital signatures, trust conditions are changed to the following list: * data is not tampered * signing certificate was time valid at signing time: signing time is within signing cert's validity * Neither certificate was revoked before signature generation * both, signing and timestamp certificates chain up to trusted root CAs (regardless of their time validity, just must be in trust store).…

That's weird. The blog post that answer links to implies that even if the timestamp certificate AND signing certificates are revoked on a date following the purported timestamp, then the signature is still trusted. That doesn't make sense to me: If the certificates are compromised, an attacker could backdate the timestamp to whatever he wanted and sign anything. What's the thinking here?

> implies that even if the timestamp certificate AND signing certificates are revoked on a date following the purported timestamp, then the signature is still trusted.

That's not how I read it. The "lifecycle table" doesn't mention the case of both signing and timestamping certificates going bad at the same time, only what happens if one of them expires or is revoked. The only mention about both certificates going bad is in the text below the table:

> But timestamped signature remains considered as a valid even if all certificates in the signing and timestamping chains are expired.

Note that it doesn't say anything about certificates being revoked.

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

#174

Post by jlgaddis » Thu, Mar 08, 2018, 7:11 AM UTC

rb808 wrote: post #17

Has anyone got a good way of managing certificates in the wild? With no real management and staff turnover I've seen a bunch of expired certificate problems. EDIT: presumably you need your client apps/libraries in the field write back when they use a cert that is <X months away from expiry.

Define "managing"?

I use simple Nagios checks for keeping an eye on certificate expiration. It's simple to set up checks for new hosts/services and I have them set to trigger an e-mail alert 30 days before expiration (20 days for certificates from Let's Encrypt). It does the job; I have yet to wake up one day to an expired certificate.

Apparently, this ("send me an e-mail before my certificate expires") is also the sole reason some companies even exist (i.e., it is their only product/service). It amazes me that this is something folks will pay for.

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

#175

Post by wtallis » Thu, Mar 08, 2018, 7:20 AM UTC

jlgaddis wrote: post #165

wtallis wrote: post #127

Earlier quoted context omitted.

Microsoft's driver signing model has a mode that is a giant footgun with no redeeming value. Oculus is a victim of Microsoft's bad design. They weren't trying to build in a self-destruct timer for their whole product stack, and if they were, they wouldn't have used the driver signing certificate as the lynchpin.

I find this reasoning ("footgun", Microsoft's fault) interesting when compared to the prevalent HN opinions when it comes to, for example, (unsecured) redis and memcached servers being used in DDoS attacks, or even AWS S3 buckets (with confidential or even highly classified files) being -- inadvertantly -- left wide open to the public. In those cases, "we" (as a "community", in general) often blame the people respons…

There's a use case for redis and memcached being open to the network, and a failure mode if you don't properly separate your internal network from the public Internet. There's a use case for S3 buckets that are publicly readable, if they don't contain sensitive/private information. Those features have reason to exist, even though there's potential for misuse. Secure defaults would be nice, but can't eliminate these risks.

There's no reason for drivers to have an expiration date. There's no scenario where it makes sense for the configuration that Oculus stumbled into to be possible.

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

#176

Post by wtallis » Thu, Mar 08, 2018, 7:24 AM UTC

cyrix281 wrote: post #168

wtallis wrote: post #112

Earlier quoted context omitted.

That puts the blame on Oculus, but the blame really should rest on Microsoft for enabling and enforcing a signature mode that shouldn't exist at all.

It needs to exist in an untrusted environment.. it verifies that the driver which has low level access to the computer hasn't been modified by a third party.. MS signed system binaries are the same way; it's a safeguard against malicious entities.

I'm not arguing against the entire concept of driver signing, just one specific nuance of Microsoft's driver trust model. There is a place for driver signing and signature checking, but de-trusting a driver that you were perfectly happy to give kernel-level access yesterday doesn't make sense.

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

#177

Post by anonymfus » Thu, Mar 08, 2018, 7:29 AM UTC

wtallis wrote: post #30

ThatPlayer wrote: post #22

Earlier quoted context omitted.

Because it was the certificate for the Windows driver, and Windows requires signed drivers.

The problem isn't that Windows requires drivers to be signed. The problem is that Windows allows drivers to have an expiration date. If Windows verifies a driver's signature at the time the driver is installed, the driver should be considered trustworthy for as long as it remains installed on that system. There's no reason to re-verify the signature every time the driver is used .

Is there such thing as a driver installation for the kernel, or it's just few filesystem operations?

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

#178

Post by jlgaddis » Thu, Mar 08, 2018, 7:30 AM UTC

girvo wrote: post #167

jlgaddis wrote: post #165

Earlier quoted context omitted.

I find this reasoning ("footgun", Microsoft's fault) interesting when compared to the prevalent HN opinions when it comes to, for example, (unsecured) redis and memcached servers being used in DDoS attacks, or even AWS S3 buckets (with confidential or even highly classified files) being -- inadvertantly -- left wide open to the public. In those cases, "we" (as a "community", in general) often blame the people respons…

> I'm having trouble trying to reconcile these two seemingly opposing viewpoints. I mean this with all respect... but why? You're talking about different opinions expressed by completely different people. HN isn't a monolith.

Sure, there are plenty of different opinions here on HN. If there wasn't, these discussion threads would be boring and useless.

My point was: in most threads, there's a common opinion or viewpoint shared by most, along with a few "detractors". In general, though, the overwhelming "predominant" opinions (within/on a particular subject) are pretty consistent from one thread to the next.

For example, the "it's the end user's fault, not the developers" thing I mentioned earlier. That seems to be, pretty consistently, the "belief of the majority". Here, though, it's the complete opposite. Instead of saying "the end user (Oculus) screwed up" (which, IMO, they certainly did, FWIW), it's "Microsoft made a footgun which caused this".

That said, I have now made it through the rest of the comments in this thread and it seems that this viewpoint isn't as widespread as it first appeared. Perhaps I just jumped to a conclusion much too quickly; there's obviously plenty of fingers pointing at Oculus as well.

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

#179

Post by Kenji » Thu, Mar 08, 2018, 7:43 AM UTC

StavrosK wrote: post #15

Why is it possible for a device that is basically a display to stop working because a certificate expired? This future worries me.

This future worries me.

That's not the future. That's the present! Which is even more worrying.

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

#180

Post by jlgaddis » Thu, Mar 08, 2018, 7:48 AM UTC

wtallis wrote: post #175

jlgaddis wrote: post #165

Earlier quoted context omitted.

I find this reasoning ("footgun", Microsoft's fault) interesting when compared to the prevalent HN opinions when it comes to, for example, (unsecured) redis and memcached servers being used in DDoS attacks, or even AWS S3 buckets (with confidential or even highly classified files) being -- inadvertantly -- left wide open to the public. In those cases, "we" (as a "community", in general) often blame the people respons…

There's a use case for redis and memcached being open to the network, and a failure mode if you don't properly separate your internal network from the public Internet. There's a use case for S3 buckets that are publicly readable, if they don't contain sensitive/private information. Those features have reason to exist, even though there's potential for misuse. Secure defaults would be nice, but can't eliminate these r…

Really? No reason whatsoever?

I'm not being facetious, FWIW. I know a fair amount about PKI, in general (probably in more depth and intricate detail than the average HN'er, actually), but I'm not a developer and I know very little about code signing in particular (and even less when it comes to the Microsoft world of code signing).

I do find it kinda hard to believe that there's no use case whatsoever for this particular configuration (code signing w/o an included timestamp from a TTP), though. I certainly understand why a timestamp can be valuable (as it would in this case) but what isn't clear is that there is "no scenario" whatsoever where the lack of a timestamp might be acceptable or perhaps even desired.

As I said, though, I don't know enough about code signing specifically to know what these scenarios might be but I can't imagine there isn't even one of them.