4 ms·

No they can't. UaF is impossible in memory safe languages like Go. Concurrency doesn't matter here. Only thing you would get is logical errors resulting in cras

No they can't. UaF is impossible in memory safe languages like Go. Concurrency doesn't matter here. Only thing you would get is logical errors resulting in crashes or weird behavior.

rndgermandude 7y ago
Javascript, that the exploit uses, is a memory safe language too, at lest in theory... None of the languages around, that are in major production use, are really completely memory safe in practise. There is always a runtime lurking under it, most times a libc (not in Go tho, IIRC) and assortment of various libraries written in memory unsafe languages and always a kernel. While it's probably harder to exploit Go, as, as far as I know, most of the Go runtime is written in Go, it's not impossible, just a lot less likely.
- saagarjha 7y ago
  Go depends on libc on certain platforms, such as macOS.
- staticassertion 7y ago
  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/

No they can't. UaF is impossible in memory safe languages like Go. Concurrency doesn't matter here. Only thing you would get is logical errors resulting in crashes or weird behavior.

rndgermandude 7y ago

Javascript, that the exploit uses, is a memory safe language too, at lest in theory... None of the languages around, that are in major production use, are really completely memory safe in practise. There is always a runtime lurking under it, most times a libc (not in Go tho, IIRC) and assortment of various libraries written in memory unsafe languages and always a kernel. While it's probably harder to exploit Go, as, as far as I know, most of the Go runtime is written in Go, it's not impossible, just a lot less likely.

saagarjha 7y ago
Go depends on libc on certain platforms, such as macOS.
staticassertion 7y ago
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/