This is what should happen in IT. Someone looks for a vulnerability; find it. Determine if the project owners need prior warning; then go public. Everyone becomes aware of the issue and upgrades their systems accordingly. Problem solved.<p>Criminalizing those who are only looking to harden the security of public facing infrastructures from those who don't have good intentions doesn't help anyone. And while I'm sure that Geohot and Reece took on this challenge as more of a fun exercise, we've all benefited from the results.<p>So I look forward to reading more articles where hackers attempt to exploit Go binaries; and subsequently how to avoid my own Go binaries from being exploited the same way.<p>(i should add, this is a more generalized comment. I'm aware that this specific attack isn't a practical real-world vulnerability)
If we are writing programs to write to arbitrary memory, wouldn't it be easier to write them in C? :)<p><pre><code> int main(int argc, char *argv) {
*((char *)addr_to_write) = val_to_write;
}
</code></pre>
On a more serious note: this is a fun compiler bug, but I wouldn't call it a valid exploit. If you have the power to run your own binary on a system, then of course you can write to any memory the process has access to.
I'm really excited to see people working on security in Go. Security by default is supposed to be one of Go's "features" at some level. (The typical example: your first several C programs probably had many buffer overflow vulnerabilities, but it's very likely none of your Go programs ever will.) Still, Go hasn't been very thoroughly tested and security hardened, so I'm hoping to see many more exploits like this discovered and ironed out in the near future.
For some reason, the website is not loading here and Google's cache dates from before the release of the exploit, so the post is hidden.<p>Anybody has a mirror or some way to access the post?