351–360 of 517 posts
Honestly what I mostly want is to not have memory leaks. Which somehow stopped being a focus at some point
This is harder than it looks as soon as you start counting abandoned memory (stuff that's still referenced but not actually used.)
Earlier quoted context omitted.
Whether you can a segfault if you access an out-of-bounds address or not is part of the language implementation. An implementation that guarantees a segfault for out-of-bounds accesses is memory safe.
You can't really guarantee that all out-of-bounds accesses will segfault, because memory protection mechanisms are not that granular. (And actual memory segmentation, that did have the required granularity, has fallen out of use - though CHERI is an attempt to revive it.) That's why a segfault is treated as something to be avoided altogether, not as a reliable error mechanism. What you can say though (and the point I…
Earlier quoted context omitted.
You can't really guarantee that all out-of-bounds accesses will segfault, because memory protection mechanisms are not that granular. (And actual memory segmentation, that did have the required granularity, has fallen out of use - though CHERI is an attempt to revive it.) That's why a segfault is treated as something to be avoided altogether, not as a reliable error mechanism. What you can say though (and the point I…
How granular the memory protection mechanism is is part of the implementation.
Earlier quoted context omitted.
It's a contrived type confusion bug. It reads 42h because that address is hardcoded, and it does something that ordinary code doesn't do. If you were engaged to do a software security assessment for an established firm that used Go (or Python, or any of the other mainstream languages that do shared-memory concurrency and don't have Rust's type system), and you said "this code is memory-unsafe", showing them this exam…
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.
Earlier quoted context omitted.
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.
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.
Denial of service can absolutely be a security issue, as can any correctness bug if it leads to unintended behavior or corrupted data.
Earlier quoted context omitted.
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.
> 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.
Earlier quoted context omitted.
I'm sure I could come up with a bunch of examples but the first thing that jumps into my head is the Docker ecosystem.
Yeah, that’s not nearly the level of big I was thinking of. It’s not a browser or WhatsApp or Word. Admittedly, Go is popular among developers. And there are some public examples of client-side attacks targeting developers and security researchers specifically. Such attacks could hypothetically go after something like Docker. But, searching now, every single example I can find seems to either exploit a non-developer-…
Earlier quoted context omitted.
"Memory safety" is a security term, not a PLT term.
That's a statement without source and even if it was widely accepted as true it doesn't imply the fact that something needs to be exploitable to be considered a security issue. We are full of CVEs without a known way to be exploited.
Earlier quoted context omitted.
The thread you're commenting has already discussed everything this comment says. If you've got concerns about our security page, I think you should first take them to the ISRG Prossimo project. https://www.memorysafety.org/docs/memory-safety/
In this thread I linked the fly.io security page because it helps us establish that one can talk about _languages_ as being memory safe specifically, which is something it seems you're rejecting as a concept in the parent and other comments. (In a separate comment about "what do people claim about Go anyhow", I linked the memorysafety.org page, but I did not expect it to help in getting you to the understanding that…
Earlier quoted context omitted.
In this thread I linked the fly.io security page because it helps us establish that one can talk about _languages_ as being memory safe specifically, which is something it seems you're rejecting as a concept in the parent and other comments. (In a separate comment about "what do people claim about Go anyhow", I linked the memorysafety.org page, but I did not expect it to help in getting you to the understanding that…
Huh? No, I'm not. Go is a memory-safe programming language, like Java before it, like Python, Ruby, Javascript, and of course Rust.