12 comments

[ 2.8 ms ] story [ 34.8 ms ] thread
Should add (2021) to title.
Good catch. Added. Thanks!
Am I the only one who finds it highly annoying that exclusive domain names are registered for individual CVEs?
let's go further .. domain name means visibility and costs money.. so whoever builds and pays for "cipherleaks dot com" intends to make a business out of it..

Let's imagine a worst case scenario, where thousands of highly skilled hours are put into building common infrastructure ("barn raising") among capable people with implied social promises but not cash, and then a second wave ("cattle ranchers") comes in and starts collecting money for CVEs and pushing out any claims for compensation by authors..

this scenario is playing out in the EU (CRA laws) or de-facto in the USA (VC startups) right now.. with the monetization of CVEs , but foot-dragging and long speeches for compensation of OSS engineering. make sense?

A domain name can be got for 30$/yr more or less.

Vanity is just another explanation, and the hope that the CVE gets "famous" like heartbleed or spectre or meltdown.

Source: I'm the owner of 3 domains (not security related fwiw) but zero businesses.

A .com is $10 or so a year
yeah but you can't fight human psychology. If I say CVE-2014-0160, only a handful of people will know what I mean, but if I say heartbleed, there's a lot more recognition. Until the singularity happens and we're post-scarcity, people need money and recognition helps get more of that, however indirectly.
I'm really not sure why this is popping up here, but we may as well exchange information: who has actually used secure those enclave-like solutions? I mean various kinds of setups where some userspace code is in a way more privileged than kernel code (insofar as access to that process' memory goes).
There are a few categories of usage for enclaves (well, more broadly, Trusted Execution Environments):

1) Clouds (you mostly trust the provider, but maybe not fully. And you want to make sure they don’t have anything up their sleeves. Consider the FBI vs Apple encryption dispute)

2) Intra-corporation stuff as a mitigation against hacked users, malicious insiders, and malware (think crypto oracles for terminating SSL, requiring bootchain attestation before giving corporate credentials)

3) The more icky category: Places where you distrust your own customer (DRM, and probably eventually, game anticheat)

The userspace code being more privileged than kernel code has never really been true. Maybe arguably true for SGX, but even then, all you get is the ability to prove you were initialized in the “right” way. All the other TEEs have a kernel mode component (they are typically ways of running attestable VMs).

If only there was a way to make the third use case illegal... Users should be treated as GODS on the machine they own. They should be the one holding all the keys to the kingdom. There should not be any hardware/firmware feature that can subvert this authority by either concealing things, or snitching on the user. My machine should not work against me.
Software bluray player DRM used to use SGX. But Intel discontinued that on desktop chips so they no longer can do that.
I work at a business that sells a product built on Intel SGX.