All of Oculus’s Rift headsets have stopped working due to an expired certificate
231–240 of 390 posts
Re: All of Oculus’s Rift headsets have stopped working due to an expired certificate
#232This 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.
Re: All of Oculus’s Rift headsets have stopped working due to an expired certificate
#233Earlier 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…
and efficiency of computation is the least of my worries. i would like things to just work.
Re: All of Oculus’s Rift headsets have stopped working due to an expired certificate
#234It's free to use right now, and sends your reminders on Slack and Email.
Re: All of Oculus’s Rift headsets have stopped working due to an expired certificate
#235Earlier quoted context omitted.
It's still Oculus fault because they didn't use a timestamped signature. A timestamped signature on the binary would have it kept working and that's how MS intents it to work. You can leave it out if you have the desperate longing for having your software break suddenly without reason like Oculus just did.
And that's where MS is at fault: drivers without timestamped signatures should be treated as faulty. This would prevent these errors in the first place.
Besides, literally every codesigning blogpost/tutorial/guide/etc I found tells you to use a timestamping server so the guys and girls and Oculus must have skipped the critical parts of whatever they used.
Re: All of Oculus’s Rift headsets have stopped working due to an expired certificate
#236Earlier quoted context omitted.
It's not an expiration on the signed executable but an expiration on the ability of the certificate to sign an executable.
This is the exact right answer. And for this to work at all, the signature needs a timestamp so that the OS can know that the certificate was valid at the time of signing. But for some reason (signtool.exe, etc) makes it really hard to get this done properly. This is especially true in a CI-setting, where this is one of those areas where signing and timestamping essentially makes a reliably and deterministic process…
It doesn't take a lot more work than I think.
> But for some reason (signtool.exe, etc) makes it really hard to get this done properly.
In our experience, signtool doesn't make this "really hard to get this done properly". The CI for our primary product uses a remote server for timestamping at signing. While that server doesn't go down constantly, it does go down at least once a month. This is not an artifact of signtool but the vendor.
To have security it is far better to have something fail and not sign than to sign incorrectly. The opposite, get it done attitude at all costs, was the likely cause of this article having been written about Oculus. In this case the cost was signing something incorrectly, due to a misunderstanding of the very basics of certificates, and bricking the already working primary product of the company.
Microsoft has a mode for loading unsigned drivers. Every Windows developer should already know about this. If a junior developer without this knowledge is in control of a critical build process, that's the problem not signtool.
I've met far too many people who treat a lack of security knowledge as a positive or a badge of honor of some kind. It's not a positive, it's something undesirable and a loss-leader for employers.
Re: All of Oculus’s Rift headsets have stopped working due to an expired certificate
#237Earlier quoted context omitted.
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…
Yes, you’re talking about the proliferation of declarative APIs over explicit, imperative ones. My pet theory is that because we typically understand our needs before we understand the code paths required to fulfill them, our V1 APIs are usually a declarative “this is what should be” interface. Then we spend days or months making it happen and by the time we understand the required code paths, we’ve totally baked our…
Many declarative interfaces are the culmination of decades of work on re-inventing the wheel at the imperative level. The relational model and SQL databases are a great example of this - “we’ve solved these problems below this line mostly, please move on and focus up the stack closer to the customer/user”. It became a multi billion dollar industry as it nailed the 80/20 rule for data management.
And for a large class of problems this remains solid, despite a perpetual subset of engineers that think they can do better than the declarative interface and engine and build an alternative. Sometimes it makes sense to be adventurous and drop back to the imperative level - SQL databases fell over in recent years was the scalability of the underlying engine for the largest uses. But a Postgres or MySQL endures as a great declarative abstraction over a very complicated set of issues.
Re: All of Oculus’s Rift headsets have stopped working due to an expired certificate
#238Earlier quoted context omitted.
It’s not even necessary to test. Once you’ve done it a few times codesigning is a piece of cake. But there a few flags you absolutely pay attention to or else it’s going to bite you in the ass way down the line.
> It’s not even necessary to test. Once you’ve done it a few times codesigning is a piece of cake. Presumably this is what Oculus thought and so how they got in this mess.
BTW, most commercial installer progtams will apply a valid timestamp if codesigning is enabled. So to save ~$1000 someone decided the tools built into Visual Studio were good enough. Anyone that ships commercial software that does more than a basic install into C:\program files will know to spend the money, it’s worth it.
Re: All of Oculus’s Rift headsets have stopped working due to an expired certificate
#239Shameless plug: To avoid such embarrassing situations in future, I've made https://monitorcertificates.com/ . It's free to use right now, and sends your reminders on Slack and Email.
1. Automated the certificate process to auto-renew at least a year before expiry.
2. Have counter-signatures
3. Have anyone at all use any sort of calendar system to just check in on it to be sure.
But I guess being one of the largest tech companies on earth doesn't mean you don't have massive oversights.
Re: All of Oculus’s Rift headsets have stopped working due to an expired certificate
#240Earlier 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?
Of course this sorta falls apart if you consider large bad actors could have legit timestamp certs over a period of time and then use those historic certs on backdated servers to counter-sign a stolen signing cert. It would appear as a legit signed and counter-signed cert done when the signing certs were valid.