> The fact is that Go doesn't admit memory corruption vulnerabilities, and the way you know that is the fact that there are practically zero exploits for memory corruption vulnerabilities targeting pure Go programs, despite the popularity of the language.

Another way to word it: If "Go is memory unsafe" is such a revelation after its been around for 13 years, it's more likely that such a statement is somehow wrong than that nobody's picked up on such a supposedly impactful safety issue in all this time.

As such, the burden of proof that addresses why nobody's ran into any serious safety issues in the last 13 years is on the OP. It's not enough to show some theoretical program that exhibits the issue, clearly that is not enough to cause real problems.

▲

zozbot234 4 days ago | parent [-]

There's no "revelation" here, it's always been well known among experts that Go is not fully memory safe for concurrent code, same for previous versions of Swift. OP has simply spelled out the argument clearly and made it easier to understand for average developers.

▲

tptacek 4 days ago | parent [-]

It's made what would be a valid point using misleading terminology and framing that suggests these are security issues, which they simply are not.

"One could easily turn this example into a function that casts an integer to a pointer, and then cause arbitrary memory corruption."

No, one couldn't! One has contrived a program that hardcodes precisely the condition one wants to achieve. In doing so, one hasn't even demonstrated even one of the two predicates for a memory corruption vulnerability (attacker control of the data, and attacker ability to place controlled data somewhere advantageous to the attacker).

What the author is doing is demonstrating correctness advantages of Rust using inappropriate security framing.

▲

zozbot234 4 days ago | parent [-]

> misleading terminology and framing that suggests these are security issues

Could you quote where exactly OP has misleadingly "suggested" that these concerns lead to security issues in the typical case?

> attacker control of the data, and attacker ability to place controlled data somewhere advantageous to the attacker

Under this definition the Rowhammer problem with hardware DRAM does not qualify as a genuine security concern since it inherently relies on fiddly non-determinism that cannot possibly be "controlled" by any attacker. (The problem with possible torn writes in concurrent Go code is quite similar in spirit; it's understood that an actually observed torn write might only occur rarely.) Needless to say there is a fairly strong case for addressing these problems anyway, as a matter of defence in depth.

> correctness advantages of Rust

Memory safety in OP's sense is not exclusive to Rust. Swift has it. Even Java/C# cannot access arbitrary memory as a result of torn writes. It would be more accurate to say that OP has identified a correctness issue that's apparently exclusive to Go.

▲

tptacek 4 days ago | parent [-]

I quoted directly from the article.

▲

zozbot234 4 days ago | parent [-]

To use your definition, that quote is clearly making a point about correctness, not necessarily about real-world security.

	▲	tptacek 4 days ago \| parent [-]
		As long as we agree that there isn't a meaningful security implication, we don't need to keep litigating.