Secure Modular Runtimes
guybedford.com
Secure Modular Runtimes
1–10 of 10 posts
Re: Secure Modular Runtimes
#2Spectre 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.
Re: Secure Modular Runtimes
#3Spectre 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].
Re: Secure Modular Runtimes
#4Spectre 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.
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.
Re: Secure Modular Runtimes
#5Spectre 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.
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"
which is a very interesting point.
Re: Secure Modular Runtimes
#6This 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.
Re: Secure Modular Runtimes
#7Spectre 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.
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 st…
> could be hardened through formal verification
Yeah... but that only works by you verifying your assumptions. If your assumptions are wrong, you remain screwed. I'm all for it but it's not perfection.
Re: Secure Modular Runtimes
#8Spectre 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.
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 permissi…
Read again, but from the other side of the looking-glass; imagine that you have a bunch of code in E or some other object-capability-safe language, and you want to audit it for Spectre vulnerabilities. As the article makes clear, other concerns are taken care of structurally by E's design; how might E be changed to also help mitigate Spectre?
Re: Secure Modular Runtimes
#9Earlier quoted context omitted.
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 permissi…
Read again, but from the other side of the looking-glass; imagine that you have a bunch of code in E or some other object-capability-safe language, and you want to audit it for Spectre vulnerabilities. As the article makes clear, other concerns are taken care of structurally by E's design; how might E be changed to also help mitigate Spectre?
Capabilities can mitigate exfiltration of spectre'd data exactly as described in the bit I quoted. That's mitigation of, not proof against, but it's something.
I'm afraid I don't see your point.
Re: Secure Modular Runtimes
#10Spectre 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.
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.