Golang heap corruption during garbage collection | Hacker News Reader

Golang heap corruption during garbage collection

blog.stalkr.net

60 points__Joker29 comments

To be clear: this another attack where the attacker is writing malicious Golang code and getting you to run it; ie, it's an attack that proposes Golang be situated in the same place Javascript is.

Of course, in its normal configuration, Golang can simply run shell commands, read/write files, &c.

It is still extremely valuable to understand how exploits like this are constructed.

To also be clear: This is a bigger deal than it might be due to the way Go handles external dependencies. Github hacks might get nasty.

What? How does that make sense? External dependencies, being themselves standard Golang code, can also run shell commands, read/write files, &c.

Maybe referring to go packages having no metadata and being unsigned, so if a github account was hacked and you used go get on a third party pkg you could end up compiling unexpected exploit code into your binary?

Again not sure what that has to do with heap corruption.

Ah, I see what you're getting at now I think - an exploit would not be required as you are blindly running the go code anyway (e.g. in a web server it could read/write files etc just as the web server process can). Might being able to cause heap corruption let the code affect server operations in unexpected ways though? For example bypassing restrictions on an app plugin in some sort of CMS, bypassing restrictions on something like db access or passwords in memory, or bypassing a sandbox like that on play.golang.org.

I don't think Go is especially vulnerable in this regard, as you noted below ruby gems are also mostly unsigned just now, however I think there was a move to have those signed after the recent problems, and Go's pkgs don't have metadata or a facility to do this AFAIK. So that could be seen as a weakness (though one shared by many other package management systems).

Yes, that's exactly what I meant. Imagine if say, a database adapter had a backdoor added, and no one noticed.

You simply do not use "go get" on 3rd party repos in production. It's not different from pip or gem.

Well... Ruby developers almost invariably do use gem in production. And of course, gems are not signed.

I suspect a lot of people will (as they do with gems or pips), given the extra trouble forking all your dependencies and keeping track of updates to them causes. Many companies don't have a team to take care of this process, just developers, and the easy route with bundler or with go get is to use the 3rd party code directly, though with bundler you can pin to a major/minor version at least. I'm not even sure there is much to gain security-wise by forking a gem/pkg/pip, save perhaps delays in your process that might save you from deploying an exploit before it is used, unless you have someone do a code audit on all the code. That's practical in a large org but not in many small shops.

I agree there's very little security difference anyway though between go get and bundle install for gems say (don't agree with the OP there), but go get has no clear way to add metadata like out-of-band code signatures as gems or pips do.

The introduction of package management directly into the language tooling core is a very good move for the language designers. It is a highly modern touch, which will enable rapid development and a common understanding of packages. Other languages have developed such add-ons, but only after a period of confusion.

If the designers want to really take it to the next level, they should introduce, possibly with idiomatic behavior but preferable with syntax, the idea of version pinning or at least version hinting within the "import" syntax.

At the risk of some controversy, I think that if Go's core developers are serious about encouraging good software engineering, they should drop "go get" (presumably in Go 2). It seems to me that subrepositories / submodules at the version control level, with support for pinning, are the best way to manage dependencies.

Google's internal developers operate in a vastly different world from the one most of us are used to, always building from the head of a single, massive Perforce repository.

When your world enforces the assumption that the latest version of a dependency is stable and compatible, 'go get' is a perfectly reasonable solution.

> At the risk of some controversy, I think that if Go's core developers are serious about encouraging good software engineering, they should drop "go get" (presumably in Go 2). It seems to me that subrepositories / submodules at the version control level, with support for pinning, are the best way to manage dependencies.

That's how 'go get' works.

No it doesn't, you can't request or pin a specific version. You just get whatever is in HEAD when you pull.

> No it doesn't, you can't request or pin a specific version. You just get whatever is in HEAD when you pull.

You get the dependency at a version control level, at a known-good version (because you pulled from the master branch) at the time you pulled, and after that it's up to you to update it.

I guess he means the import directly from github and other online code repos are not signed or checked in any manner. Still imports from online code repositories are supposed to be a convenience to get started faster and should be replaced by a better dependency management in production.

It'd be interesting to know whether this sort of exploit would be possible when targeting a web server as opposed to building a vulnerable go binary. Perhaps fuzzing the Golang built-in web server would be a good exercise for security researchers looking for a way to improve Go security.

There's a cute and slightly scary use of go playground to demonstrate the exploit at the end of the article:

http://play.golang.org/p/fOxl250j8w

(no longer works as play.golang was patched).

No, I don't think so.

If you mean no to the first bit, that's reassuring. play.golang.org is something of a special case as it tries to run code in a sandbox. I'd be more interested in exploits which attack web server processes or db drivers with malicious input as those are more likely to actually be used in the wild.

*Go

Golang is often preferred as it's much easier to search for and no need to disambiguate between other things called Go (Chinese board game, 1999 film).

I wish they had renamed it to Issue9 when they still had the chance.

Issue 9 from Google Labs.

As well as the other similarly named programming language: Go! ( http://en.wikipedia.org/wiki/Go!_(programming_language) )

To be honest, I hate the name "Go" even for vocally conversing. It's such a common term that the context is completely lost with verbal communication so I'm often having to explain things in a long winded way. eg "It's programmed in Google's language named 'Go'".

Google probably should have just released it as "Golang" from the start to save a lot of trouble and confusion.

Yes

Google should have known better what's a good "googable" name. Golang is a good compromise