| |
| ▲ | ralfj 4 days ago | parent | next [-] | | > It reads 42h because that address is hardcoded, It is trivial to change this example into an arbitrary int2ptr cast. > Go (or Python, or any of the other mainstream languages that do shared-memory concurrency and don't have Rust's type system), As the article discusses, only Go has this issue. Python and Java and JavaScript and so on are all memory-safe. Maybe you are mixing up "language has data races" and "data races can cause the language itself to be broken"? > If people want to make PLT arguments about Rust's correctness advantages, I will step out of the way and let them do that. But this article makes a security claim, and that claim is in the practical sense false. This article makes a claim about the term "memory safety". You are making the claim that that's a security term. I admit I am not familiar with the full history of the term "memory safety", but I do know that "type safety" has been used in PLT for many decades, so it's not like all "safety" terms are somehow in the security domain. I am curious what your definition of "memory safety" is such that Go satisfies the definition. Wikipedia defines it as > Memory safety is the state of being protected from various software bugs and security vulnerabilities when dealing with memory access, such as buffer overflows and dangling pointers. My example shows that Go does not enforce memory safety according to that definition -- and not through some sort of oversight or accident, but by design. Out-of-bounds reads and writes are possible in Go. The example might be contrived, but the entire point of memory safety guarantees is that it doesn't matter how contrived the code is. I'm completely fine with Go making that choice, but I am not fine with Go then claiming to be memory safe in the same sense that Java or Rust are, when it is demonstrably not the case. | | |
| ▲ | tptacek 4 days ago | parent [-] | | The problem isn't that you couldn't hardcode a scarier value; it's that you have to demonstrate a plausible scenario in realistic code where an attacker controls both the value and the address it's written to. While you're wondering why I keep claiming Go is a memory-safe language, you can also go ask the ISRG, which says the same thing I am at (checks notes) https://www.memorysafety.org/. | | |
| ▲ | ralfj 4 days ago | parent [-] | | > While you're wondering why I keep claiming Go is a memory-safe language, you can also go ask the ISRG, which says the same thing I am at And yet Go violates the definition they give -- it doesn't prevent out-of-bounds accesses. (And just to be sure we're talking about the same thing, I'm specifically talking about Go here. All the other languages on their list are actually memory safe, as far as I know.) > you have to demonstrate a plausible scenario in realistic code where an attacker controls both the value and the address it's written to. So your definition of memory safety includes some notion of "plausible" and "realistic"? Neither https://www.memorysafety.org/docs/memory-safety/ nor Wikipedia have such a qualification in their definition. It would help if you could just spell out your definition in full, rather than having us guess. | | |
| ▲ | 4 days ago | parent | next [-] | | [deleted] | |
| ▲ | HAL3000 4 days ago | parent | prev | next [-] | | > So your definition of memory safety includes some notion of "plausible" and "realistic"? Neither https://www.memorysafety.org/docs/memory-safety/ nor Wikipedia have such a qualification in their definition. It would help if you could just spell out your definition in full, rather than having us guess. This is a strawman argument, you're arguing semantics here. You're a smart person, so you know exactly what he means. The perception created by your article is that people shouldn't use Go because it's not memory-safe. But the average developer hearing "not memory-safe" thinks of C/C++ level issues, with RCEs everywhere. Unless you can show a realistic way this could be exploited for RCE in actual programs, you're just making noise. Further down the thread, you admit yourself that you're in a PLT research bubble and it shows. | | |
| ▲ | dcow 4 days ago | parent | next [-] | | You definitely shouldn’t use Go, but it’s not because of the discussion in TFA. I jest, rhetorically. Seriously, why are we bashing a researcher for being academic? This makes no fucking sense. Nobody claimed anywhere that people should stop using Go. | |
| ▲ | esoterae 4 days ago | parent | prev | next [-] | | Did you not notice how this started over someone saying "That's not the definition of memory safety" and then prevaricating about the bush when asked to provide their definition? Your theory that this is an argument over semantics is correct, but not fully understood. | |
| ▲ | ralfj 4 days ago | parent | prev | next [-] | | > The perception created by your article is that people shouldn't use Go because it's not memory-safe. Uh, where exactly am I saying or implying that?
I am, in fact, saying that Go is much closer to memory-safe languages than to C, safety-wise. But I am arguing that the term "memory safe" should only be used for languages that actually went through the effort of thinking this problem through to the end and plugging all the holes through which memory safety violates can sneak in. Go is 99% there, but it's falling slightly short of the goal. I think that's a useful distinction, and I am disappointed that it is regularly swept under the rug, which is why I wrote this blog post. You are free to disagree, I never expected to convince everyone. But I think I gave some people some new food for thought, and that's all I can hope for. | |
| ▲ | hdevalence 4 days ago | parent | prev [-] | | > you're arguing semantics here Yes, semantics — what do things mean, exactly? — is the subject of the discussion here and is actually quite important in general. |
| |
| ▲ | tptacek 4 days ago | parent | prev [-] | | You're just wrong about this. The ability to write contrived code that does an out-of-bounds write, or to induce crashes, doesn't violate the notion of "memory safety" as an ordinary term of art. | | |
| ▲ | ralfj 4 days ago | parent | next [-] | | Yeah I understand that that's how you like to use the term, you've been very clear about that. What I am curious about is whether that's just you. Because the source you gave last time, https://www.memorysafety.org/docs/memory-safety/, doesn't agree with what you are saying, and neither does Wikipedia. I am honestly curious here. I am a PLT researcher so I am in a bubble where people use the term consistently with how I use it. You are the first person I meet (for some notion of "meet" ;) that uses the term differently. But without external sources it's hard to judge how wide-spread your definition (that you still haven't spelled out...) is. | | |
| ▲ | tptacek 4 days ago | parent | next [-] | | Again: my usage of the term is widespread enough that the ISRG uses it to refer to Go as well, as does, well, basically everybody else in the industry. I think you've just message-boarded yourself into believing this is a live debate. There is no sequence of words you're going to come up with to convince me that everybody is wrong when they say "Go is a memory safe language". | | |
| ▲ | ralfj 4 days ago | parent [-] | | You keep making arguments by assertion without giving sources, so :shrug: yeah this isn't going to go anywhere. I think we actually agree on all of the factual points here, we just don't agree on how languages should be categorized/labeled according to their guarantees in both a theoretical and a practical sense, and that's largely a subjective matter anyway. So, happy to agree to disagree here. |
| |
| ▲ | Thaxll 4 days ago | parent | prev [-] | | Go is memory safe, what do you think of: https://www.nsa.gov/Press-Room/Press-Releases-Statements/Pre... U.S. and International Partners Issue Recommendations to Secure Software Products Through Memory Safety They recommand Go among other language in their paper. https://media.defense.gov/2023/Dec/06/2003352724/-1/-1/0/THE... | | |
| ▲ | ralfj 4 days ago | parent [-] | | Yeah, Go is often listed with memory-safe languages, I know that. And yet when people define memory safety, Go usually fails to satisfy that definition. That's why I was asking for a definition of memory safety that would include Go. | | |
| ▲ | kiitos 2 days ago | parent [-] | | I suppose Go's notion of memory safety is satisfied by forbidding pointer arithmetic, and, maybe somewhat transitively, preventing arbitrary out-of-bounds access to memory. It definitely satisfies this notion of memory safety. Maybe this notion of memory safety is not considered to be correct, or relevant, or whatever, by whomever. That's fine. |
|
|
| |
| ▲ | rowanG077 4 days ago | parent | prev | next [-] | | Did you consider that the organization can be wrong? > Memory safety is a property of some programming languages that prevents programmers from introducing certain types of bugs related to how memory is used. Since memory safety bugs are often security issues, memory safe languages are more secure than languages that are not memory safe. That is the definition they give. Since Go does not "prevent programmers from introducing certain types of bugs related to how memory is used." it does not fall under this definition. They can list go as memory safe, but then either they disagree with their own definition or made the mistake of adding Go to that list. Memory safety is not a spectrum. You are either memory safe or unsafe. The spectrum is in the unsafety. Go is obviously less unsafe than C for example. | | |
| ▲ | kiitos 2 days ago | parent [-] | | > Memory safety is not a spectrum. You are either memory safe or unsafe. if there is one takeaway from this discussion, i think it must be that memory safety does not have any single, commonly-accepted, or objective definition -- and that it is pretty obviously a spectrum, not a boolean | | |
| ▲ | rowanG077 20 hours ago | parent [-] | | I could agree to that if the people who claim it would at least put it in their definition. But as it stands it indeed is a boolean. You have to give a definition of something like: "Memory safety denotes the degree to which a programming language guides and protects developers from memory‑related errors—ranging from minimal, manual checks to comprehensive static and runtime enforcement—through mechanisms like strong typing, ownership or borrow checking, and garbage collection." And then also include modern C++ in their lists. because by all accounts it is memory safe by that definition. |
|
| |
| ▲ | zozbot234 4 days ago | parent | prev [-] | | Then the "security" definition is totally useless, because even C can be memory safe. What about pointers, malloc(), free(), unchecked enums etc. etc.? Oh, those are just "contrived" language features you're not really supposed to use. You can write FORTRAN in any language! | | |
| ▲ | tptacek 4 days ago | parent [-] | | C is the archetypical memory-unsafe language. When you've reached the point where you're simultaneously arguing that C is memory-safe and Go isn't, you should recognize you've made a wrong turn somewhere. | | |
| ▲ | zozbot234 4 days ago | parent [-] | | My point with those comparisons is that you have not bothered to define a reasonable and verifiable standard for what counts as "contrived" code - which is what ultimately seems to determine whether a language is memory safe, according to your definition. |
|
|
|
|
|
| |
| ▲ | nicoburns 4 days ago | parent | prev | next [-] | | You are however replying to thread where a Dropbox engineer calls it "a right of passage" to introduce such bugs to their codebase. Which suggests that it is by no means unheard of for these problems to crop up in real-world code. | | |
| ▲ | tptacek 4 days ago | parent | next [-] | | Again: introducing surprising correctness bugs? Crashing programs? Absolutely. I don't know how many different ways I can say that my concern here is the misuse of a security term of art. Dropbox engineers do not have as a rite of passage introducing or finding RCE vulnerabilities in Go code. Would that it were so! My job would be much more interesting. | | |
| ▲ | zozbot234 4 days ago | parent [-] | | > correctness bugs? Crashing programs? Absolutely. Denial of service can absolutely be a security issue, as can any correctness bug if it leads to unintended behavior or corrupted data. | | |
| ▲ | tptacek 4 days ago | parent [-] | | If that's where we're at, where unhandled exceptions are the security issues we're hanging on, I'll consider my argument won. | | |
| ▲ | zozbot234 4 days ago | parent [-] | | That might be a reasonable argument if you were guaranteed an unhandled exception in this instance. Unfortunately that's not the case. | | |
| ▲ | tptacek 4 days ago | parent [-] | | If you could demonstrate something better than that, we wouldn't be arguing about the severity of DOS attacks. |
|
|
|
| |
| ▲ | samus 4 days ago | parent | prev | next [-] | | Doesn't Dropbox write a lot of Python extensions in C for speedup? | | |
| ▲ | pclmulqdq 4 days ago | parent [-] | | Excuse me, but in this thread we are bashing go, not making logical arguments. | | |
| |
| ▲ | blub 4 days ago | parent | prev [-] | | Many FAANG & co engineers are overrated.
If every new hire is introducing concurrency bugs in a Golang codebase, refactor, do better review and maybe use concurrency questions instead of leetcode. I’ll take tptacek’s word over most FAANG type on such topics if we’re doing appeals to authority. The guy is very practical, unlike the Rust community which is incredibly focused on theoretical correctness instead of real-world experiences. |
| |
| ▲ | stickfigure 5 days ago | parent | prev | next [-] | | I have recently come to the conclusion that everything I ever thought was "contrived" is currently standard practice in some large presently existing organization. | | |
| ▲ | tptacek 5 days ago | parent [-] | | Take that to the Apple bounty program with your crasher bug and tell them they should pay out as if you'd confirmed RCE, see how it goes. This is an engineering question; it's not about vibes. It's not even always the case that corrupted data structures (or even pointers) in C code are exploitable. You need attacker control of data and where it goes in memory. It's far less often the case in Python or Go --- in fact, it's basically never the case. As evidence for that claim: the zero memory corruption RCEs in all of shipping Go code, of which there is a lot. | | |
| ▲ | NitpickLawyer 5 days ago | parent [-] | | Dunno about Apple, but goog sometimes pays out bugs that are "theoretical" in the way you describe. That is, you show that there's a bug somewhere, but you can't "reach" it from user data. They'll pay less than a PoC, obviously, but will pay. YMMV, etc. |
|
| |
| ▲ | jacquesm 4 days ago | parent | prev [-] | | My own takeaway after looking at corporate codebases for four decades is that the state of the art in software development at banks, governments, insurance companies, airlines, health care and so on is such that I long for the time before the internet. Sure, those mainframes from the 80's weren't bullet proof either. But you first had to get to them. And even if the data traveled in plain text on leased lines (point-to-point but not actually point-to-point (that would require a lot of digging), no multiplexing) you had to physically move to the country where they were located to eavesdrop on them, and injecting data into the stream was a much harder problem. |
|
