3 ms·

Javascript is used to perform the exploit. The renderer, where the vulnerable code exists (I assume), is C++. The problem with protecting a C++ codebase like a

Javascript is used to perform the exploit. The renderer, where the vulnerable code exists (I assume), is C++. The problem with protecting a C++ codebase like a JS renderer is that the attacker has HUGE amounts of control. They can literally already execute arbitrary code in the renderer, making information leaks and other techniques much easier. ASLR was never intended to protect against an attacker with such a level of control.

rndgermandude 7y ago
> Javascript is used to perform the exploit. The renderer, where the vulnerable code exists (I assume), is C++. Yes, that way my point. There is a runtime and/or VM and/or stdlib under these "memory safe" languages and these things are never fully written in memory safe languages themselves, at least as far as the current state of affairs goes. And even then, they run on insecure hardware (rowhammer and spectre anybody?). Would using a language with better memory safety and other guarantees like Rust be better to write these things? Most certainly, as the attack surface becomes smaller and e.g. Rust would prevent a lot of programming mistakes in the first place. Would that be a complete silver bullet, tho? Nope. So I agree with you that using a language with C++ isn't exactly "optimal" to implement these runtimes that are meant to run untrusted code. I just didn't like that the OP declared "memory safe languages like Go" to be a silver bullet. >ASLR was never intended to protect against an attacker with such a level of control. ASLR is not a protection. It's an additional roadblock put in place to make things harder for attackers once shit already hit the fan.
- staticassertion 7y ago
  Oh, I see. I misunderstood your point. > Would that be a complete silver bullet, tho? Nope. I don't think anyone would disagree! > So I agree with you that using a language with C++ isn't exactly "optimal" Yeah, I think the distinction here is that I don't consider it "suboptimal" I consider it to be an absolute disaster. I would call rust "suboptimal" in that the language contains some soundness holes and the stdlib contains unsafe - issues, but practically still a massive improvement.
- MaxBarraclough 7y ago
  > There is a runtime and/or VM and/or stdlib under these "memory safe" languages and these things are never fully written in memory safe languages themselves, at least as far as the current state of affairs goes. The ideal solution is to go beyond safe languages, and use formally verified compilers and interpreters. 'CompCert', for instance, is a formally verified C compiler [0]. (Strictly, it's a compiler for a very-nearly-complete subset of standard C.) (As an aside, I Googled for a formally verified Ada compiler, but I couldn't see any sign of one. I find that surprising.) No reason the same couldn't be done for Rust, and/or its standard library. Would be a lot of work, of course, but it would close the door on some of the bugs you have in mind. It wouldn't save you from operating-system bugs, but formally verified operating systems are a possibility too. [1] > And even then, they run on insecure hardware (rowhammer and spectre anybody?). True, but I think it's safe to say that insecure hardware isn't usually near the top of our practical security concerns. I imagine one can greatly reduce the risk of such vulnerabilities if high-performance isn't required, and AMD/Intel aren't the only options. [0] http://compcert.inria.fr/compcert-C.html http://compcert.inria.fr/compcert-C.html [1] https://sel4.systems/About/seL4/ https://sel4.systems/About/seL4/

rndgermandude 7y ago

> Javascript is used to perform the exploit. The renderer, where the vulnerable code exists (I assume), is C++. Yes, that way my point. There is a runtime and/or VM and/or stdlib under these "memory safe" languages and these things are never fully written in memory safe languages themselves, at least as far as the current state of affairs goes. And even then, they run on insecure hardware (rowhammer and spectre anybody?). Would using a language with better memory safety and other guarantees like Rust be better to write these things? Most certainly, as the attack surface becomes smaller and e.g. Rust would prevent a lot of programming mistakes in the first place. Would that be a complete silver bullet, tho? Nope. So I agree with you that using a language with C++ isn't exactly "optimal" to implement these runtimes that are meant to run untrusted code. I just didn't like that the OP declared "memory safe languages like Go" to be a silver bullet. >ASLR was never intended to protect against an attacker with such a level of control. ASLR is not a protection. It's an additional roadblock put in place to make things harder for attackers once shit already hit the fan.

staticassertion 7y ago
Oh, I see. I misunderstood your point. > Would that be a complete silver bullet, tho? Nope. I don't think anyone would disagree! > So I agree with you that using a language with C++ isn't exactly "optimal" Yeah, I think the distinction here is that I don't consider it "suboptimal" I consider it to be an absolute disaster. I would call rust "suboptimal" in that the language contains some soundness holes and the stdlib contains unsafe - issues, but practically still a massive improvement.
MaxBarraclough 7y ago
> There is a runtime and/or VM and/or stdlib under these "memory safe" languages and these things are never fully written in memory safe languages themselves, at least as far as the current state of affairs goes. The ideal solution is to go beyond safe languages, and use formally verified compilers and interpreters. 'CompCert', for instance, is a formally verified C compiler [0]. (Strictly, it's a compiler for a very-nearly-complete subset of standard C.) (As an aside, I Googled for a formally verified Ada compiler, but I couldn't see any sign of one. I find that surprising.) No reason the same couldn't be done for Rust, and/or its standard library. Would be a lot of work, of course, but it would close the door on some of the bugs you have in mind. It wouldn't save you from operating-system bugs, but formally verified operating systems are a possibility too. [1] > And even then, they run on insecure hardware (rowhammer and spectre anybody?). True, but I think it's safe to say that insecure hardware isn't usually near the top of our practical security concerns. I imagine one can greatly reduce the risk of such vulnerabilities if high-performance isn't required, and AMD/Intel aren't the only options. [0] http://compcert.inria.fr/compcert-C.html http://compcert.inria.fr/compcert-C.html [1] https://sel4.systems/About/seL4/ https://sel4.systems/About/seL4/