Top all-time · #3248
StalkR
Personal blog · blog.stalkr.netsecurityprogramming
StalkR's personal blog at blog.stalkr.net covers security and programming. Since 2013, 24 different Hacker News readers have linked it 31 times, most often “Golang data races to break memory safety”. The last post was in 2022, but the archive is still widely read.
Too few sampled comments (27) to say how often HN recommends it.?
Why HN links it
HN commenters cite StalkR's posts, mainly on Go data races and memory safety, including a 2015 post on breaking memory safety with data races and a 2022 post on a universal Go exploit. They use them as evidence in discussions of language safety.
Summarised by Claude from a sample of 27 HN comments that link here. Each comment is marked recommending, critical or neutral (citing without judging); how this works.
Blog of a security enthusiast
Most-linked posts?
- Golang data races to break memory safety13 people · 16 mentions · first linked 2018-03-25
- Universal Go exploit using data races, no imports6 people · 7 mentions · first linked 2022-06-03
- Golang heap corruption during garbage collection2 people · 2 mentions · first linked 2013-06-04
- /2015/04/golang-data-races-to-break-memory-safety.html?m=12 people · 2 mentions · first linked 2019-11-02
What Hacker News says?
What? Sorry, that doesn't make the least amount of sense. If you have a VM your code is DATA! You can have say format string bugs in managed languages too, see for example: http://blog.stalkr.net/2013/06/golang-heap-corruption-during... I'm sorry, but you're agrument here is plain bullshit. Using your logic the whole kernel/browsers etc should be written in a managed language. A browser is basically a VM for webpage…
Comment linking /2013/06/golang-heap-corruption-during-garbage.html
on “The Heartbleed Bug”Submitted Golang heap corruption during garbage collection as a story · 60 points
HN discussionTo be clear, yes. The issue is with how Go's "interface{}"s (and some other types - like slices, etc) work - it's two pointers that can't be written to atomically, which means you can get into a situation where your objects are invalid. https://blog.stalkr.net/2015/04/golang-data-races-to-break-m... Here you can find a POC. You could argue that this is contrived, but it's also not going to be fixed . This is in cont…
Comment linking /2015/04/golang-data-races-to-break-memory-safety.html
on “The Insecurity Industry”Submitted Universal Go exploit using data races, no imports as a story · 2 points
HN discussion> I can assure you that you cannot access undefined memory regions by doing this in Go. Current implementation of slices and interfaces in Go is not memory safe in presence of data races: https://blog.stalkr.net/2022/01/universal-go-exploit-using-d...
Comment linking /2022/01/universal-go-exploit-using-data-races.html
on “Rust Is Hard, Or: The Misery of Mainstream Programming”Submitted Golang data races to break memory safety as a story · 1 points
HN discussionI've seen Qt Creator segfault due to the CMake plugin doing some strange QStringList operations on an inconsistent "implicitly shared" collection, that I guess broke due to multithreading (though I'm not sure exactly what happened). In RSS Guard, performing two different "background sync" operations causes two different threads to touch the same list collections, producing a segfault. (These are due to multiple thre…
Comment linking /2015/04/golang-data-races-to-break-memory-safety.html
on “A case against security nihilism”>> 70% of security defects in memory-safe languages are probably also memory safety problems. > That doesn't make any sense at all I'm sure it's not true—70% is way too high—but the real number isn't 0% as you might expect. In particular, (most? all?) non-Rust languages that claim or appear to be memory-safe can have data races. In Go for example, those can be exploitable. [1] And Rust is memory-safe...in safe code,…
Comment linking /2015/04/golang-data-races-to-break-memory-safety.html
on “Chromium project finds that 70% of security defects are memory safety problems”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…
Comment linking /2022/01/universal-go-exploit-using-data-races.html
on “There is no memory safety without thread safety”Somewhat related, I learned a surprising fact recently: Go is not actually memory safe. In particular because atomicity is only guaranteed for word size values, double word values(interface pointers, slices) can introduce memory unsafety in the presence of concurrency[0]. It's one of those things that feels obvious when you see it. 0: https://blog.stalkr.net/2015/04/golang-data-races-to-break-m...
Comment linking /2015/04/golang-data-races-to-break-memory-safety.html
on “Writing secure Go code”It's worth noting that Go's value types are not actually memory safe, however, since it allows nontrivial concurrent mutations to shared multiword objects (as described in https://blog.stalkr.net/2015/04/golang-data-races-to-break-m... ). Unless that got fixed recently somehow? I believe in most of the other languages you mention, value types are restricted in various ways to avoid that problem (for instance, mutati…
Comment linking /2015/04/golang-data-races-to-break-memory-safety.html
on “Java’s new garbage collector promises low pause times on multi-terabyte heaps”Go is not memory safe (though is certainly safer than C++). Various Go constructs like interfaces and slices are implemented via non-atomic multiword structs, and data races may result in invalid values leading to memory corruption, etc. See https://blog.stalkr.net/2015/04/golang-data-races-to-break-m...
Comment linking /2015/04/golang-data-races-to-break-memory-safety.html
on “Gokrazy: A pure-Go userland for Raspberry Pi 3 appliances”Here you go: https://blog.stalkr.net/2015/04/golang-data-races-to-break-m... What's even worse is that Go code is not (outside of Linux/ some distros) compiled with ASLR.
Comment linking /2015/04/golang-data-races-to-break-memory-safety.html
on “Chrome 0-day exploit used in Operation WizardOpium”The race condition exploits you're thinking of are not trivial and need specific code to pull off, unlikely to be a mistake like in C/C++. You just don't find them in normal Go programs. Source (scroll down to the conclusion section): https://blog.stalkr.net/2015/04/golang-data-races-to-break-m...
Comment linking /2015/04/golang-data-races-to-break-memory-safety.html?m=1
on “Chrome 0-day exploit used in Operation WizardOpium”> Memory safe [...] trivial concurrent programming As this post demonstrates, data races are trivial and common in Go. Because many of the core types (interface, slice, map) are non-thread-safe multiword structures, they also break memory safety: https://blog.stalkr.net/2015/04/golang-data-races-to-break-m...
Comment linking /2015/04/golang-data-races-to-break-memory-safety.html
on “Data Race Patterns in Go”The slice is simply unsynchronized, so a user of the slice may pull out one array but a length that was for a different array. https://blog.stalkr.net/2015/04/golang-data-races-to-break-m...
Comment linking /2015/04/golang-data-races-to-break-memory-safety.html
on “Updating the Go Memory Model”Not easy, but definitely possible: https://blog.stalkr.net/2015/04/golang-data-races-to-break-m... > We have to admit that exploiting this requires a fairly specific situation in which there is a data race we could trigger and some structs with function pointers around.
Comment linking /2015/04/golang-data-races-to-break-memory-safety.html
on “Updating the Go Memory Model”Very interesting, thank you! Looking at the attack vector ( https://blog.stalkr.net/2019/11/the-gomium-browser-google-ct... ), this is a pretty tightly constrained circumstance where you are permitting an attacker to execute unknown Golang code within the context of your process. (perhaps like the Go Playground, if that's not starting a new process for each user.) I don't personally think that's really that applicab…
Comment linking /2019/11/the-gomium-browser-google-ctf-2019.html
on “NSA urges orgs to use memory-safe programming languages”> In other words, golang changes the risk of a data race from being a vulnerability to just a program-crashing bug. I don't believe this is true, people have demonstrated using data races to build arbitrary code execution primitives. See for example https://blog.stalkr.net/2022/01/universal-go-exploit-using-d...
Comment linking /2022/01/universal-go-exploit-using-data-races.html
on “NSA urges orgs to use memory-safe programming languages”> this has ever been proven exploitable I agree (typo exploit!) See eg https://blog.stalkr.net/2015/04/golang-data-races-to-break-m... & https://blog.stalkr.net/2022/01/universal-go-exploit-using-d... (And also people shouldn't take "nobody developed an exploit for this vulnerability yet" as any kind of strong evidence, attacks techniques always get better, never worse, over time etc - crypto algorithm people have i…
Comment linking /2022/01/universal-go-exploit-using-data-races.html
on “Patch OpenSSL on November 1 to avoid “critical” security vulnerability”https://blog.stalkr.net/2015/04/golang-data-races-to-break-m... The "Exploiting the slice type" section.
Comment linking /2015/04/golang-data-races-to-break-memory-safety.html
on “Programming Language Memory Models”Indeed, this person showed that you can read/write to arbitrary memory addresses inside of a Go program: https://blog.stalkr.net/2022/01/universal-go-exploit-using-d... Although, it's pretty useless as an exploit, since it requires you to be able to run arbitrary Go code to begin with (the author admits as much). It's _very_ unlikely that a remote attacker could exploit a data race in a regular Go program.
Comment linking /2022/01/universal-go-exploit-using-data-races.html
on “Maps and Memory Leaks in Go”pam_exec seems to be a more robust solution to login notifications than /etc/profile http://blog.stalkr.net/2010/11/login-notifications-pamexec-s...
Comment linking /2010/11/login-notifications-pamexec-scripting.html
on “Posting successful SSH logins to Slack”> Level 2 - memory safe and data races allowed > Languages where parallelism is memory safe, but can still lead to data races. > This includes Java and Go. Despite this common misconception, parallel Go is absolutely not memory safe: https://blog.stalkr.net/2015/04/golang-data-races-to-break-m...
Comment linking /2015/04/golang-data-races-to-break-memory-safety.html
on “A vision of a multi-threaded Emacs (2022)”Search for "go language slice race condition": [1] [1] http://blog.stalkr.net/2015/04/golang-data-races-to-break-me...
Comment linking /2015/04/golang-data-races-to-break-memory-safety.html
on “Channels in Golang”Go can have memory unsafety leading to arbitrary memory reads and writes by having an interface replaced by another thread (go interfaces use 2 words, one for the vtable and another for the data. It does not replace these in a thread safe way, so one can use a vtable to work with an unexpected data pointer. Folks have shown this allows the kinds of arbitrary memory reads/writes that folks normally ban in their defin…
Comment linking /2015/04/golang-data-races-to-break-memory-safety.html?m=1
on “Memory Safety”Changes to multi-word pointers can cause UB due to race conditions in Go because only changes at the word level are atomic. See: https://blog.stalkr.net/2015/04/golang-data-races-to-break-m...
Comment linking /2015/04/golang-data-races-to-break-memory-safety.html
on “Memory Safety”The same author has a post from 2022 [1]. > Is it possible to achieve arbitrary code execution on any Go version, even with PIE, and with no package import at all, just builtins? Yes! Whether it's capture the flag is irrelevant, IMO, because anything that's allowed by the compiler will emerge given enough complexity. 1: https://blog.stalkr.net/2022/01/universal-go-exploit-using-d...
Comment linking /2022/01/universal-go-exploit-using-data-races.html
on “The NSA advises move to memory-safe languages”It's unfortunate that there's no mention that not all these languages are equally safe. Go isn't memory safe when using goroutines. See: Golang data races to break memory safety: https://blog.stalkr.net/2015/04/golang-data-races-to-break-m...
Comment linking /2015/04/golang-data-races-to-break-memory-safety.html
on “The NSA advises move to memory-safe languages”The current implementation is not memory safe. Go uses 128 bit structs for interfaces and slices and assumes that they are updated atomically (when they are not). It's possible to exploit this to read/write arbitrary memory and to execute arbitrary code. It appears that in practice this is very difficult so the issue is ignored. https://blog.stalkr.net/2015/04/golang-data-races-to-break-m...
Comment linking /2015/04/golang-data-races-to-break-memory-safety.html
on “Gokrazy – Go Appliances”
