This is an excellent, in-depth and thoughtful article. I'd say the only thing it omits, and I do think is crucial, is not using X where X is unnecessary. You can close a lot of security holes just by doing that. Still a great read.
Spectre seems serious. Even the E family of languages (E, Monte, Joule, Grace), which have similar lineage to ECMAScript but have always been focused on isolation, don't have ready answers for how to mitigate Spectre and related attacks.
I think that hardware-effect attacks are going to be the primary thorn in our side for the next few decades, even if we all agree to switch to object-capability systems immediately.
Guy's arguing that there are still benefits to applying security boundaries within execution envs which are vulnerable to spectre memory reads since it would limit the ability to exfiltrate. (There was a variant which could write to memory as well [1].) There was some discussion on twitter about this which I found interesting [2].
Definitely agree that we should switch to object-capability systems.
Also, both hardware and software could be hardened through formal verification. Usually the focus is software, but given the recently exposed flaws, hardware verification seems sorely needed.
Standardizing on ECC memory and encrypted memory would help. Looks like encrypted memory is happening on all new x86 business-focused processors, but ECC is still far too uncommon which means RowHammer is still an issue.
And greatly simplified instruction sets would help, but that is probably the least likely to happen.
AIUI spectre is pretty much unrelated to this. The article is mainly about securing JS. Spectre allows sidestepping anything. The only point where spectre and capabilities touch, that I can see, is
"The second thing to note here is that if you have a true capability system and can carefully control network access, then the capability to exfiltrate (basically to use fetch), can itself be treated as a critical permission. Secrets might be discovered but not as easily shared"
Why would I rely on hard and slow to execute hardware attacks if I can just have you run my shellcode before you've even started to run my packaged library? The amount of insanity that people get away with in their installer scripts that you invoke via `npm install` is insane as is.
throwaway_pdp09|5 years ago
Kednicma|5 years ago
I think that hardware-effect attacks are going to be the primary thorn in our side for the next few decades, even if we all agree to switch to object-capability systems immediately.
pfraze|5 years ago
1 https://arxiv.org/abs/1807.03757v1
2 https://twitter.com/domenic/status/1298045068633407490
nwah1|5 years ago
Also, both hardware and software could be hardened through formal verification. Usually the focus is software, but given the recently exposed flaws, hardware verification seems sorely needed.
Standardizing on ECC memory and encrypted memory would help. Looks like encrypted memory is happening on all new x86 business-focused processors, but ECC is still far too uncommon which means RowHammer is still an issue.
And greatly simplified instruction sets would help, but that is probably the least likely to happen.
throwaway_pdp09|5 years ago
"The second thing to note here is that if you have a true capability system and can carefully control network access, then the capability to exfiltrate (basically to use fetch), can itself be treated as a critical permission. Secrets might be discovered but not as easily shared"
which is a very interesting point.
eptcyka|5 years ago