Hacker News Reader

Comment by zozbot234 | Hacker News Reader

> This is why C++ needs to be retired; and why we need to use safer languages.

These problems can easily happen in a language like Go, unfortunately. Go is memory safe for sequential code, but that guarantee does not extend to in-process concurrency - Goroutines can access shared state without synchronization, and create memory unsafety.

View on HN

But not in Rust. Go isn't exactly a bastion of safety. It's memory safe due to the GC, but it has a weak type system, so logic bugs are not well guarded against.

> It's memory safe due to the GC

That gets debatable as soon as you start using concurrency, like I said. There are idiomatic patterns in concurrent Go that are very much not safe.

What do you mean?

It has a GC, right? So use-after-free is impossible, no?

On the other hand, Go code is a lot easier to audit.

The kind of logic bug that the Rust compiler prevents due to stronger typing is typically a crash in Go, not a security issue.

Disagree on this. In Rust I can read most of the information I need to know straight from the function signatures. In Go I have to go through every line of code (and there are often a lot of lines due to Go's lack of expressive power).

In Rust code I audit, I typically have to jump through multiple layers of abstraction and cleverness, while Go code is straight forward and boring.

I guess it's a matter of preference. If something is abstracted, then you only have to audit it once (and often you can count on someone else having audited it). With Go code, everything is new and unique, so there are a lot more opportunities to introduce bugs.

Not to be argumentative, honestly, that sound pretty laughable if you don't have an equivalent of an algebraic effect system (or similar).

A "function" in Rust can do a whole bunch of stuff that is not signaled by its type signature.

Mutability / immutability is in the function signatures, and that goes a long way. It's not as good as an effect system of course. But along with global variables barely being a thing in Rust, it goes a long way to cutting out the common course of bugs.

Rust is not safer than Go, people thinking otherwise misunderstand borrow checker vs GC.

Furthermore you're talking about memory safety vs business logic bugs, two different things.

Go is not memory-safe in the presence of concurrency. Interfaces and slices (i.e. fat pointers) are not written atomically, which can cause undefined behavior.

I haven't heard of this causing a problem in practice, though.

I never heard undefined behavior in Go like your example. This would means that not synchronizing a slice would lead to memory corruption.

Please give us a code example.

Slice values are normally copied so it's not an issue. The slice would need to be stored in a global or a struct's field and then changed while some other goroutine is reading it.

(I haven't seen this happen, though.)

Yes, not synchronizing a slice can lead to memory corruption in Go.

Here you go: https://blog.stalkr.net/2015/04/golang-data-races-to-break-m...

What's even worse is that Go code is not (outside of Linux/ some distros) compiled with ASLR.

Here's a blog post from Russ Cox (Go core team) explaining it: https://research.swtch.com/gorace

Are all Go fat pointers two words? If so, it would be pretty trivial to make them atomic on AArch64 using LDP/STP.

Unfortunately slices are 3 words. (Besides, AArch64 isn't a common target for Go. On x86 you'd need cmpxchg16b or something.)

Go isn’t really a C++ replacement. I‘m not sure if that solves this particular issue, Rust is provably free of data races (excluding unsafe).

is it possible to have arbitrary code execution in Go? I'm just curious.

Go has a few escape hatches like the unsafe package, but outside from that, I'm pretty sure arbexec isn't achievable in Go. The compiler inserts bounds check to prevent overflows, UAF isn't really achievable thanks to the GC, etc...

You can have UAF in Go due to slicing in the presence of concurrency: the implementation doesn't use multi-word atomics to update fat pointers like slices and interfaces. That said, it's not easy to do so.

What do you mean by memory unsafety? A stale read would be bad, but wouldn't lead to arbitrary code execution.

A 'stale' read of atomic data may be fine (it wouldn't really be "unsynchronized" in that sense), but as soon as you're dealing with stuff that's not completely atomic in-hardware and need actual synchronization, there's a potential of breaking expected invariants and creating further unsafety as a consequence of that.

I agree a stale read is bad. And I am surprised that the Go designers have repeated many past mistakes. It is possible to design a concurrent high-level language that does not have such issues, despite the hardware. For example, if all communication is done via channels, then synchronisation can be automatically performed during channel read/write. For shared mutable state, Haskell's software transactional memory and Erlang's Mnesia are both excellent examples of safely dealing with it.

The issue wrt. Go is not with communication via channels in and of itself, but rather with using channels to share pointers to in-memory data. This is idiomatic in Go, people do it all the time even though it's what introduces unsafety.

Yes, but my point is that it's a flaw in the language to allow this. Not all high-level languages share Go's problems. However, even Go would be a huge safety improvement over C++.

Go is actually one of the best in terms of design. Not every language has to be so complex. Go is easy to use and that's the point. Concurrency in it is best in class in many regards and that's what allowed the language to pretty much became THE language for backend, infrastructure and other web related things.

Rust is in completely different spectrum and doesn't compete with Go. It's much more complex, harder to write and read. That's the cost of safety. For kernel or browser engine - that's the compromise people are willing to take. For other applications - better use something else.

> Go is actually one of the best in terms of design.

I respectfully disagree. Go's primary goal was to be (superficially) easy to use and familiar. Because of this, it fails to tackle the big issue with doing concurrency in most prior mainstream languages. Go has mutable state deeply baked into the language and makes it difficult to work with immutable data. Go is not necessarily easy to use if ones goal is to build correct concurrent software.

Go's call-by-value semantics give you similar benefits. Just different tradeoffs (because there are downsides to immutable data structures).

My understanding of Go's design aesthetic is that it prefers to be explicit about things that could impact performance, which is probably why it prefers simple data structures with explicit synchronization.

You don't need to go that far. Go could have been memory-safe if slices were one word instead of three (like Java's arrays), and interfaces were one word instead of two (like Java's interfaces).

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.

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.

Go depends on libc on certain platforms, such as macOS.

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.

> 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.

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.

> 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

[1] https://sel4.systems/About/seL4/

My bullshit detector is at 3.6

Go has a garbage collector (i.e memory safety) & race detection tooling built in. https://golang.org/doc/articles/race_detector.html

Even if a race condition bug does sneak in, it won't be as catastrophic as C/C++.

Writing concurrent code is hard in any language. There's no magic bullet & Go or Rust are not immune to concurrency bugs. If anything, tools like the race detector should always come built in and every dev working on concurrent code should use one.

GC does not provide memory safety at a system level, it has the same issues as C++ in poorly programmed code once compiled. Also C++ has "memory safety" idioms similar to garbage collection through reference counting and RAII.

Google has a C++ race detector based on the Go one and it did not detect this issue (or was ignored).

Neither of those things you listed reduce the severity of the bug, and both are available in well written C++ code as google tends to do.

What do you mean? If you don't use unsafe package you can't have the same problem as C/C++ so it is memory safe. The bug in Chrome can't happen in Go without unsafe usage.

That is categorically not true.

Go compiles down to machine code, it has a stack and heap, it has structures on that stack and heap, and it has data races; those are all of the required components for a use after free. You can have data races compiled by the stock go compiler without the use of unsafe (also, why have race detector tooling if this is false?). It would probably be easier to exploit than here even because one wouldn't even need to bother with the ASLR pointer exfiltration they had to do here.

It may be harder to write exploitable code, but memory safety does not guarantee runtime memory safety. Especially in the face of concurrency.

The race condition exploits you're thinking of are not trivial and need specific code to pull off, unlikely to be a mistake like in C/C++. You just don't find them in normal Go programs.

Source (scroll down to the conclusion section): https://blog.stalkr.net/2015/04/golang-data-races-to-break-m...

Having race data in your Go code doesn't mean it will be exploitable like C or C++. Same reason with Java / C# when you don't use native code.

Reply on news.ycombinator.com