Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

There is no memory safety without thread safety

ralfj.de

Post reply on HN
Print view View original

151–160 of 517 posts

Re: There is no memory safety without thread safety

#151

Post by 9rx »

stouset wrote: post #139
FiloSottile wrote: post #86

I have never seen real Go code (i.e. not code written purposefully to be exploitable) that was exploitable due to a data race. This doesn’t prove a negative, but is probably a good hint that this risk is not something worth prioritizing for Go applications from a security point of view. Compare this with C/C++ where 60-75% of real world vulnerabilities are memory safety vulnerabilities. Memory safety is definitely a…

Maintenance in general is a burden much greater than CVEs. Exploits are bad, certainly, but a bug not being exploitable is still a bug that needs to be fixed. With maintenance being a "large" integer multiple of initial development, anything that brings that factor down is probably worth it, even if it comes at an incremental cost in getting your thing out the door.

> but a bug not being exploitable is still a bug that needs to be fixed.

Do you? Not every bug needs to be fixed. I've never see a data race bug in documented behaviour make it past initial development.

I have seen data races in undocumented behaviour in production, but as it isn't documented, your program doesn't have to do that! It doesn't matter if it fails. It wasn't a concern of your program in the first place.

That is still a problem if an attacker uses undocumented behaviour to find an exploit, but when it is benign... Oh well. Who cares?

Re: There is no memory safety without thread safety

#152

Post by kibwen »

minitech wrote: post #33
kibwen wrote: post #17

Earlier quoted context omitted.

The statement "there is no memory safety without thread safety" does not suggest that memory safety is sufficient to provide thread safety. Instead, it's just saying that if you want thread safety, then memory safety is a requirement.

> Instead, it's just saying that if you want thread safety, then memory safety is a requirement. It's saying the opposite – that if you want memory safety, thread safety is a requirement – and Java and C# refute it.

> It's saying the opposite

Indeed, you're correct, I interpreted the implications in reverse.

Re: There is no memory safety without thread safety

#153

Post by mirashii »

adamwk wrote: post #142
chadaustin wrote: post #62

Every time this conversation comes up, I'm reminded of my team at Dropbox, where it was a rite of passage for new engineers to introduce a segfault in our Go server by not synchronizing writes to a data structure. Swift has (had?) the same issue and I had to write a program to illustrate that Swift is (was?) perfectly happy to segfault under shared access to data structures. Go has never been memory-safe (in the Rust…

Crashing on shared access is the safe thing to do

An intentional exit by a runtime is a safe crash. A segfault is not, and is here a clear sign that memory safety has been violated.

Re: There is no memory safety without thread safety

#154

Post by lossolo »

ameliaquining wrote: post #129
lossolo wrote: post #114

Earlier quoted context omitted.

I can show you a trivial POC in C/C++ where someone opens a socket and ends up with a buffer overflow or UAF, both cases leading to memory corruption due to sloppy programming, and both easily exploitable for RCE. Can you show me any reasonable proof of concept (without using unsafe etc.) in Go that leads to similar memory corruption and is exploitable for RCE?

https://blog.stalkr.net/2022/01/universal-go-exploit-using-d... This example hardcodes the payload, but (unless I've badly misunderstood how the exploit works) that's not necessary, it could instead be input from the network (and you wouldn't have to pass that input to any APIs that are marked unsafe). The payload is just hardcoded so that the example could be reproduced on the public Go Playground, which sandboxes t…

Yeah, it looks like CTF like POC, not what I would call reasonable code by any measure:

https://github.com/StalkR/misc/blob/master/go/gomium/exploit...

The tight goroutine loop that flips one variable between two different struct types just to win a race is not something a typical developer writes on purpose. The trick to "defeat" compiler optimizations by assigning to a dummy variable inside an inline function. Carefully computing the address difference between two slices to reach out of bounds, then using that to corrupt another slice’s header. I mean calling mprotect and jumping to shellcode is outright exploit engineering, not business logic and it's not part of the attackers payload.

Chances of exact PoC pattern showing up in the wild by accident is basically zero.

Re: There is no memory safety without thread safety

#155

Post by 9rx »

stouset wrote: post #130
9rx wrote: post #95

Earlier quoted context omitted.

On the flip side, what would be the point? There are already a million other languages that have everything and the kitchen sink. Not going down the same road is the only reason it didn't end up on the pile of obscure languages nobody uses.

Having the weight of Google behind it is the primary reason it didn't end up on the pile of obscure languages nobody uses.

Oh...? Dart never gained much steam. And let's not forget about Carbon! Can you name even just one person who has tried Carbon? Have more than a handful of people even heard of Carbon?

I will grant you that Carbon is still in its infancy, but when Rust was in the same youthful stage we never heard an end to all the people playing with it. You, even if not tried it yourself, definitely knew about it.

You've made up a fun idea, but reality doesn't support it. Google has not shown its weight carries anything. They have really struggled to get any for-profit business units off the ground since they gained the weight, never mind their hobbies! If anything, Google is detrimental to a project.

Re: There is no memory safety without thread safety

#156

Post by kibwen »

tialaramex wrote: post #113
kibwen wrote: post #79

Earlier quoted context omitted.

> The sad thing is that most languages with threads have a default of global variables and unrestricted shared memory access. This is the source of the vast majority of data corruption and races. Processes are generally a better concurrency model than threads Modern languages have the option of representing thread-safety in the type system, e.g. what Rust does, where working with threads is a dream (especially when y…

Originally Rust is something altogether different. Graydon has written about that extensively. Graydon wanted tail calls, reflection, more "natural" arithmetic with Python style automatic big numbers, decimal for financial work and so on. The Rust we have from 1.0 onwards is not what Graydon wanted at all. Would Graydon's language have been broadly popular? Probably not, we'll never know.

Even in pre-1.0 Rust, concurrency was a primary goal; there's a reason that Graydon listed Newsqueak, Alef, Limbo, and Erlang in the long list of influences for proto-Rust.

Re: There is no memory safety without thread safety

#157

Post by tekne »

swiftcoder wrote: post #150
Thaxll wrote: post #149

Earlier quoted context omitted.

Rust does have loop counter overflow.

Theoretically you can construct a loop counter that overflows, but I don't that there is any reasonable way to do it accidentally? Within safe rust you would likely need to be using an explicit .wrapping_add() on your counter, and explicitly constructing a for loop that wasn't range-based...

Well, in debug mode yes, but in release mode overflow is wrapping by default unless you explicitly set a flag to make it panic.

Re: There is no memory safety without thread safety

#158

Post by nemothekid »

tptacek wrote: post #20
chowells wrote: post #19

Earlier quoted context omitted.

You mean like the program in the article where code that never dereferences a non-pointer causes the runtime to dereference a non-pointer? That seems like evidence to me.

An exploit against a real Go program that relies on memory corruption.

This is no true Scotsman for programming languages.

I could also argue C is memory safe and all the exploits that have been made weren’t real C programs

Re: There is no memory safety without thread safety

#159

Post by tptacek »

amluto wrote: post #34
tptacek wrote: post #20

Earlier quoted context omitted.

An exploit against a real Go program that relies on memory corruption.

https://github.com/golang/go/issues/34902 https://www.cloudfoundry.org/blog/cve-2020-15586/ I don’t see any evidence that anyone wrote an RCE exploit for this, but I also don’t see any evidence of anyone even trying to rule it out.

What about this particular bug do you think makes it likely to be exploitable? I'm not asking you to write an RCE POC, just to tell a story of the sequence of events involving this bug that results in attacker-controlled code. What does the attacker control here, and how do they use that control to divert execution?

Re: There is no memory safety without thread safety

#160

Post by tptacek »

sophacles wrote: post #105
tptacek wrote: post #20

Earlier quoted context omitted.

An exploit against a real Go program that relies on memory corruption.

I think your security background is coloring your perception of the term memory safety. Specifically the requirement that the various issues lead to exploitation. These issues can lead to many other issues that are not vulnerability in the security sense, e.g. data corruption, incorrect (but not insecure) behavior, performance issues, and more. I don't think any of those were ever dismissed or excluded from memory sa…

"Memory safety" is a security term, not a PLT term.
Post reply on HN