Comment by thinkharderdev

Comment by thinkharderdev 9 days ago

> You'll be using an idiosyncratic definition the rest of the industry does not use, but you do you.

What definition are you using that you seem to think is the one definition of memory safety that is canonical?

> don't have buffer overflows, integer overflows, use-after-frees, double frees, controllable uninitialized pointers, and all the other memory lifecycle vulnerabilities

Any guarantees about this are dependent on the language not having undefined behavior in its safe subset. Once you have undefined behavior any other guarantees made about memory safety are significantly weakened.

> where are the vulnerabilities?

I don't know of any other than code written to demonstrate the concept. But I imagine if you look at any large Golang codebase you will find race condition bugs. So the fact that you have potential undefined behavior resulting from an extremely common coding error seems like it might be something to be concerned about (to me at least). Especially given how little Golang helps you write safe concurrent code.

That's not to say that Go is therefore totally useless and everyone should stop using it now because it's "insecure". But it also seems ... unwise ... to me to just pretend it's nothing because it is hard to exploit or that we don't have any (known) examples of it being exploited.

tptacek 9 days ago

You will find race condition bugs. You will not find memory corruption vulnerabilities. Go look.

The argument is not about whether languages admit vulnerabilities --- all of them do. The argument is about whether they admit the vulnerabilities that motivate the term of art "memory safety". Go does not, at least not in any non-contrived scenario not involving "unsafe" or FFI.

As for definitions, I like what Alex wrote about this; or, you can look at ISRG's writing about it.

https://alexgaynor.net/2023/oct/02/defining-the-memory-safet...

Reply View 3 replies

thinkharderdev 9 days ago

You linked me to an article that defines an unsafe language as:
"a programming language which, by default, allows code to introduce memory-related vulnerabilities (use after free, buffer over/under flow, use of uninitialized memory, type confusion) and undefined behavior,"
Which was my whole point. The "and undefined behavior" part is absolutely essential to the definition because you can't guarantee the first part without it.
> Go does not, at least not in any non-contrived scenario not involving "unsafe" or FFI.
It absolutely does. You can find examples of code that triggers undefined behavior in this thread. You can hand-wave them away as being "contrived" (which is literally correct) but that doesn't just make the problem go away.
We had a whole collective meltdown (pun intended) over spectre and meltdown a few years back even though AFAICT there have never been any known exploits in the wild. But most people who are knowledgeable in these things still took it seriously because they realized that:
1. Just because you haven't found a specific instance of an in-the-wild exploit doesn't mean there isn't one 2. You don't want to necessarily wait because if something it exploitable in theory is will almost certainly be exploited sooner or later. And it takes time to sort this stuff out
Is this relevant to your average working dev slinging micro-services in go? No, probably not and it's probably not something you should even think about for the most part. But if you're writing a complex, mission critical system with very hard security requirements? Yeah maybe you should worry about little bit about the fact that Go is, by the definition you yourself provided me, not a memory safe language.

Reply View | 1 reply
- tptacek 9 days ago
  
  For a variety of reasons I'm confident in my interpretation of the link I provided.
  
  Reply View | 0 replies
fragmede 9 days ago

The problem with naming the language "go" is that my initial interpretation of your comment was to think that "go look" was a valgrind-esque tool for finding such things.
Too bad it's not.

Reply View | 0 replies