7 ms·

It's unfortunate that there's no mention that not all these languages are equally safe. Go isn't memory safe when using goroutines. See: Golang data races to b

It's unfortunate that there's no mention that not all these languages are equally safe. Go isn't memory safe when using goroutines. See: Golang data races to break memory safety: https://blog.stalkr.net/2015/04/golang-data-races-to-break-memory-safety.html https://blog.stalkr.net/2015/04/golang-data-races-to-break-m...

slimsag 3y ago
Adding some more for other languages: * many GC'd languages like Go, C#, Java make it harder to leak memory, while languages where reference counting is more prevalent (Python, Rust) it can be easier to leak memory due to circular references. * Languages with VMs like C#/Java/Python may be easier to sandbox or execute securely, but since native code is often called into it breaks the sandboxing nature. * Formally-verified C code (like what aerospace manufacturers write) is safer than e.g. Rust. * For maximum safety, sandboxing becomes important - so WASM begins to look appealing for non-safety-critical systems (like aerospace) as it allows for applying memory/CPU constraints too in addition to restricting all system access.
- deleted 3y ago
  [deleted]
Thaxll 3y ago
Go is memory safe, that post does not means anything in real life scenario. Do you have a single example in the last 14 years of memory safety exploit using the Go runtime? I'm talking about public and known exploit not ctf and the like.
- jonnytran 3y ago
  The same author has a post from 2022 [1]. > Is it possible to achieve arbitrary code execution on any Go version, even with PIE, and with no package import at all, just builtins? Yes! Whether it's capture the flag is irrelevant, IMO, because anything that's allowed by the compiler will emerge given enough complexity. 1: https://blog.stalkr.net/2022/01/universal-go-exploit-using-data-races.html https://blog.stalkr.net/2022/01/universal-go-exploit-using-d...
  - blincoln 3y ago
    Wow, that's super interesting. As you say, it's a contrived CTF example, but I'm pretty shocked that it's possible to read and write arbitrary process memory without importing any packages (especially unsafe, of course). I'm also surprised that a fix has been theorized at least as far back as 2010[1], but not implemented. Is adding one layer of internal pointer redirection for interfaces, slices, and strings really that much of a performance concern? [1] https://research.swtch.com/gorace https://research.swtch.com/gorace
  - Thaxll 3y ago
    Go was released in 2009 and I've never heard about any exploit and what not , by the way this is known and by design it's not new. It's all about the multi word for interface. I mean if in 14 years there was nothing it's a proof that it's not an issue. Even the attacker ack that it's not a threat. "As said before, while a fun exercise it's pretty useless in the current Go threat mode"
    - mikrotikker 3y ago
      How long was openvpn in use before we discovered heartbleed? Or bash before shellshock
zozbot234 3y ago
It's not safe when using goroutines to access shared mutable data (and most Go code does this). If you stick to message passing a.k.a. "share data by communicating" you don't run into memory unsafety. But this kind of design is more vulnerable to other concurrency issues, viz. race conditions and deadlocks.
corethree 3y ago
That's fine. Safety with concurrency doesn't exist in any language. Only rust is special in that it tries to provide safety with concurrency as well. I haven't seen any other language besides rust actually do this. The reason is obvious. There's a high cost to this type of safety. Rust is hard to use and learn and many times it's safety forces users to awkwardly organize code. And there's still the potential for race conditions even though the memory is safe, you don't have full safety.
- NSufi 3y ago
  Swift provides memory safety with concurrency as well.
trealira 3y ago
You can also cause a segfault in Go by dereferencing a null pointer. That's another example of not being entirely memory safe.
- conradludgate 3y ago
  In this case it's not memory unsafe. It is guaranteed to crash the program (or get caught). It's closer to a NullReferenceException than it is to reading from a null pointer in C. There's no memory exploitation you can pull off from this bug being in a Go program, but you could in a C program
  - trealira 3y ago
    It's only guaranteed because of the operating system's sandboxing. > It's closer to a NullReferenceException than it is to reading from a null pointer in C. No, it's exactly the same as a null pointer dereference in C, because it is literally reading from a null pointer in Go as well. In Java, the compiler inserts null checks before every single dereference and throws an exception for null references. > There's no memory exploitation you can pull off from this bug being in a Go program, but you could in a C program Provided the OS sends a SEGV signal for null pointer dereferences, I don't see there being a difference in security between C and Golang in this respect. It's a bigger problem when you're running without an operating system.
    - remexre 3y ago
      > In Java, the compiler inserts null checks before every single dereference and throws an exception for null references. Doesn't OpenJDK install a SIGSEGV handler, and generate the exception from that on a null dereference? (AFAIK, a lot of runtimes for GC'd languages that support thread-based parallelism do so anyway, because they can use mprotect to do a write barrier in hardware.)
      - trealira 3y ago
        > Doesn't OpenJDK install a SIGSEGV handler, and generate the exception from that on a null dereference? I thought I had read that they explicitly don't do that, but I can't find it anymore. You may be right. I should have checked before saying that. > (AFAIK, a lot of runtimes for GC'd languages that support thread-based parallelism do so anyway, because they can use mprotect to do a write barrier in hardware.) That's true. I guess those implementations must do something more advanced than "throw a NullPointerException if the program segfaults," given their garbage collector runtimes also rely on that signal.

slimsag 3y ago

Adding some more for other languages: * many GC'd languages like Go, C#, Java make it harder to leak memory, while languages where reference counting is more prevalent (Python, Rust) it can be easier to leak memory due to circular references. * Languages with VMs like C#/Java/Python may be easier to sandbox or execute securely, but since native code is often called into it breaks the sandboxing nature. * Formally-verified C code (like what aerospace manufacturers write) is safer than e.g. Rust. * For maximum safety, sandboxing becomes important - so WASM begins to look appealing for non-safety-critical systems (like aerospace) as it allows for applying memory/CPU constraints too in addition to restricting all system access.

deleted 3y ago
[deleted]

Thaxll 3y ago

Go is memory safe, that post does not means anything in real life scenario. Do you have a single example in the last 14 years of memory safety exploit using the Go runtime? I'm talking about public and known exploit not ctf and the like.

jonnytran 3y ago
The same author has a post from 2022 [1]. > Is it possible to achieve arbitrary code execution on any Go version, even with PIE, and with no package import at all, just builtins? Yes! Whether it's capture the flag is irrelevant, IMO, because anything that's allowed by the compiler will emerge given enough complexity. 1: https://blog.stalkr.net/2022/01/universal-go-exploit-using-data-races.html https://blog.stalkr.net/2022/01/universal-go-exploit-using-d...
- blincoln 3y ago
  Wow, that's super interesting. As you say, it's a contrived CTF example, but I'm pretty shocked that it's possible to read and write arbitrary process memory without importing any packages (especially unsafe, of course). I'm also surprised that a fix has been theorized at least as far back as 2010[1], but not implemented. Is adding one layer of internal pointer redirection for interfaces, slices, and strings really that much of a performance concern? [1] https://research.swtch.com/gorace https://research.swtch.com/gorace
- Thaxll 3y ago
  Go was released in 2009 and I've never heard about any exploit and what not , by the way this is known and by design it's not new. It's all about the multi word for interface. I mean if in 14 years there was nothing it's a proof that it's not an issue. Even the attacker ack that it's not a threat. "As said before, while a fun exercise it's pretty useless in the current Go threat mode"
  - mikrotikker 3y ago
    How long was openvpn in use before we discovered heartbleed? Or bash before shellshock

zozbot234 3y ago

It's not safe when using goroutines to access shared mutable data (and most Go code does this). If you stick to message passing a.k.a. "share data by communicating" you don't run into memory unsafety. But this kind of design is more vulnerable to other concurrency issues, viz. race conditions and deadlocks.

corethree 3y ago

That's fine. Safety with concurrency doesn't exist in any language. Only rust is special in that it tries to provide safety with concurrency as well. I haven't seen any other language besides rust actually do this. The reason is obvious. There's a high cost to this type of safety. Rust is hard to use and learn and many times it's safety forces users to awkwardly organize code. And there's still the potential for race conditions even though the memory is safe, you don't have full safety.

NSufi 3y ago
Swift provides memory safety with concurrency as well.

trealira 3y ago

You can also cause a segfault in Go by dereferencing a null pointer. That's another example of not being entirely memory safe.

conradludgate 3y ago
In this case it's not memory unsafe. It is guaranteed to crash the program (or get caught). It's closer to a NullReferenceException than it is to reading from a null pointer in C. There's no memory exploitation you can pull off from this bug being in a Go program, but you could in a C program
- trealira 3y ago
  It's only guaranteed because of the operating system's sandboxing. > It's closer to a NullReferenceException than it is to reading from a null pointer in C. No, it's exactly the same as a null pointer dereference in C, because it is literally reading from a null pointer in Go as well. In Java, the compiler inserts null checks before every single dereference and throws an exception for null references. > There's no memory exploitation you can pull off from this bug being in a Go program, but you could in a C program Provided the OS sends a SEGV signal for null pointer dereferences, I don't see there being a difference in security between C and Golang in this respect. It's a bigger problem when you're running without an operating system.
  - remexre 3y ago
    > In Java, the compiler inserts null checks before every single dereference and throws an exception for null references. Doesn't OpenJDK install a SIGSEGV handler, and generate the exception from that on a null dereference? (AFAIK, a lot of runtimes for GC'd languages that support thread-based parallelism do so anyway, because they can use mprotect to do a write barrier in hardware.)
    - trealira 3y ago
      > Doesn't OpenJDK install a SIGSEGV handler, and generate the exception from that on a null dereference? I thought I had read that they explicitly don't do that, but I can't find it anymore. You may be right. I should have checked before saying that. > (AFAIK, a lot of runtimes for GC'd languages that support thread-based parallelism do so anyway, because they can use mprotect to do a write barrier in hardware.) That's true. I guess those implementations must do something more advanced than "throw a NullPointerException if the program segfaults," given their garbage collector runtimes also rely on that signal.