Live data from Hacker News

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

techcrunch.com

161–170 of 390 posts

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

#161
post #45

Earlier quoted context omitted.

What happens when the countersigning service's cert expires?

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?

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

#162
post #70

Earlier quoted context omitted.

Not all e-books (or readers) have DRM. I understand and share your concern, but you can shift to only DRM-free e-books with your own backups and under your own control.

That's the only kind of ebooks (non-DRM) ones that I buy. Some publishers (like O'Reilly or Tor dot com) exclusively publish non-DRM books. I politely ask authors or publishers to release non-DRM ebooks when I can. Apart from best-sellers (or time sensitive books), I believe most books are stuck in the long tail of obscurity and releasing them as non-DRM won't affect their sales. This also means I don't visit pirate…

O'Reilly no longer publishes non-DRM books except via 3rd party agreements.

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

#163

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?

Take a look at the "Digital signature lifecycle table" here: https://www.sysadmins.lv/blog-en/digital-signatures.aspx

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

#164

Earlier quoted context omitted.

Does that really not sound ridiculous to you? Microsoft needs to be blamed for their certificate validation implementation because people might use it to make their software expire? Instead of just writing code that does so?

How about we stop blaming people who accidentally pressed figurative "system self-destruct" button and start asking why there are so many of those buttons everywhere? Nowadays this is a recurring theme. Simple mistakes leading to catastrophic failures at grand scale. "Just be more careful" doesn't cut it anymore, because in the software world there are just too many things to be careful about.

Because when you edit code basically every character you type have the potential to become a big red button. It’s not that developer add them for fun. And each time you develop a new functionality you have to figure out how to build a very solid glass box around the reds buttons you just created. The default being none.

Alternatively you could propose no user configurable functionalities whatsoever and rarely and carefully upgrade any dependencies (including the os) and you will create a very robust program.

But then don’t expect to end up with a wireless VR headset with an online game catalog and multiplayer capability. No but you can up with a very nice banking application developed in COBOL for sure.

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

#165

Earlier quoted context omitted.

Does that really not sound ridiculous to you? Microsoft needs to be blamed for their certificate validation implementation because people might use it to make their software expire? Instead of just writing code that does so?

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 responsible for running those services instead of the developers (or Amazon) being blamed for choosing convenience/ease-of-use over security. That is, we're often quick to say that the people running those wide open memcached servers are at fault for not properly configuring and/or securing them -- and not blaming the developers for creating "a giant footgun".

"You shouldn't be running servers on the Internet if you don't know how to properly configure them" (paraphrasing) is often stated. Yet, in this case, we're not blaming Oculus for their screwup and instead blaming Microsoft -- even though there's zero evidence (AFAIK) that Oculus even used any Microsoft tools to sign their application. (N.B.: I don't know the first thing about code signing on Windows so it may well be that using a Microsoft utility is required and, thus, just assumed by those of you who are familiar with the process. If that's the case, sorry.)

I'm having trouble trying to reconcile these two seemingly opposing viewpoints. Why is Microsoft's utility "a giant footgun" but a (OOTB) completely insecure by default, wide open by default memcached server (for example) isn't?

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

#166

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

It's more complex than a display; it's a display plus a collection of USB sensors and some low-level hooks into display management. This requires kernel-mode drivers, for good technical reasons, where a normal monitor wouldn't.

Any reason why most sensors couldn't be handled by generic HID drivers which even have dedicated VR page?

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

#167

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…

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

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

#168
post #110

Earlier quoted context omitted.

Apparently, they signed them incorrectly.

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.

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

#169

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

This kind of stuff worries me as well. Security experts generally don't seem to give a fuck about things being unusable due to security systems "Working as Designed". It just doesn't factor into their analysis. As long systems are not "compromised" in some narrowly defined sense, everything is considered fine. Generally this attitude doesn't backfire, because individual users loosing access to their data, their accou…

This isn't my experience at all. Most "security experts" I know are familiar with the so-called "CIA triad" and understand quite well that the "availability" part is just as important as the "confidentiality" and "integrity" (i.e., the "not compromised") parts.

If one doesn't, well, she isn't much of a "security expert" after all, is she? Firewalling off TCP port 80/443 at your perimeter firewalls isn't a very good solution if you're an e-commerce company selling your product on your web site -- and the "security experts" know this.

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

#170
post #62

Earlier quoted context omitted.

I think you'd run into other problems then, for example if your test machine needs to communicate with https sites powered by letsencrypt, all those sites will appear to use certs that "expired" at least 9 months ago.

It's a mess. At one point we had a backup domain controller that had gotten incorrectly setup as a time server, and was out of sync with the rest of the world, with a slight amount of drift. Randomly, our test servers would end up syncing time from that server at times, and wind up slightly off. When the time got slightly more than around five or ten minutes off, connections (over TLS encryption) from those boxes to…

In the world of Active Directory (Kerberos), issues will start appearing when time is off by as little as five minutes.
Post reply on HN