Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

cmd/compile: stack cookies #21871

Closed
markdascher opened this issue Sep 13, 2017 · 2 comments

Comments

Projects
None yet
4 participants
@markdascher
Copy link

commented Sep 13, 2017

Some local vulnerability scanners attempt to detect binaries that are compiled without stack cookies (e.g. -fstack-protector vs. -fno-stack-protector with GCC), and flag that as a vulnerability. AWS Inspector is one such example, and it flags Go binaries on Linux. I don't know how AWS Inspector works, but one might simply examine the symbol table using readelf -s, and trigger this finding if __stack_chk_fail is missing.

What should Go's stance be for this sort of thing?

  • Are there any stacks worth protecting? Without knowing all the gory details, I would imagine there's some amount of bootstrapping and interfacing with the OS using "unsafe" stacks, for lack of a better term.
  • Is there a way to include stack protectors?
  • Should any protection be included by default?
  • If stack protectors aren't necessary, why aren't they?
  • If the vendor of one of these tools is convinced that Go binaries are safe, and would like to exclude all Go binaries from this sort of scan, is there a way to do that?

I'm not necessarily for or against a change, but the only discussion I can find is in this old thread which predates the current compiler tool chain, and it would be nicer to have an open or closed issue to reference.

@ccbrown

This comment has been minimized.

Copy link

commented Sep 13, 2017

Are there any stacks worth protecting? Without knowing all the gory details, I would imagine there's some amount of bootstrapping and interfacing with the OS using "unsafe" stacks, for lack of a better term.

I don't think this question makes sense. Your understanding of stacks may be a bit off. Or maybe I'm just not understanding.

Is there a way to include stack protectors?

I'm sure it would be technically feasible to add this feature to the Go compiler. But from a user perspective, no, not currently.

Should any protection be included by default?
If stack protectors aren't necessary, why aren't they?

Go is considered memory safe for the most part. That may be a bit debatable since data races do exist, and it is possible to achieve arbitrary code execution, but it's really hard to exploit in practice. I've yet to see or hear of anyone exploiting a Go application in this way.

So my opinion is that stack protectors aren't necessary and should not be included by default.

If the vendor of one of these tools is convinced that Go binaries are safe, and would like to exclude all Go binaries from this sort of scan, is there a way to do that?

You could probably use rsc/goversion to determine if a binary is a Go binary and exclude it.

@ianlancetaylor ianlancetaylor changed the title Stack Cookies cmd/compile: stack Cookies Sep 13, 2017

@ianlancetaylor ianlancetaylor changed the title cmd/compile: stack Cookies cmd/compile: stack cookies Sep 13, 2017

@ianlancetaylor

This comment has been minimized.

Copy link
Contributor

commented Sep 13, 2017

Stack checking as implemented by -fstack-protector is designed to detect buffer overflows for buffers located on the stack. This concept is not particularly meaningful for Go, as in Go there is no pointer arithmetic and all slice and array bounds are checked.

That said, it is possible, though not simple, to set an unsafe.Pointer to the address of a variable that does not escape, and then to modify the value of that unsafe.Pointer to point to a different section of the stack, and then modify the stack in that way. However, even this kind of error is very unlikely to be caught by a stack cookie of the form used by -fstack-protector. The -fstack-protector option is designed for erroneous buffer overruns, and Go code is not written in a way that creates buffer overruns, and the only way to do it in Go is to very explicitly use unsafe.Pointer to write C style memory accesses, which nobody ever does.

So, in short, in my opinion, -fstack-protector has no use for Go.

To address your specific points.

Are there any stacks worth protecting? Without knowing all the gory details, I would imagine there's some amount of bootstrapping and interfacing with the OS using "unsafe" stacks, for lack of a better term.

No, there isn't. There is some assembly code that could in principle use stacks in an unsafe way, but -fstack-protector, which does not apply to assembly, wouldn't help there anyhow.

Is there a way to include stack protectors?

Yes, we could add this to the compiler, but we shouldn't.

Should any protection be included by default?

Not beyond the existing protection, no.

If stack protectors aren't necessary, why aren't they?

See above.

If the vendor of one of these tools is convinced that Go binaries are safe, and would like to exclude all Go binaries from this sort of scan, is there a way to do that?

Sure, just look at the symbol table. Go symbol names have periods in them, C symbol names do not.

I'll mention that Go does, of course, have an interface for calling C code, and it would be perfectly reasonable to compile that C code with -fstack-protector. That is a choice that we leave up to the programmer, and the cgo documentation (https://golang.org/cmd/cgo) explains how to set flags to use for compiling the C code used by cgo.

I'm going to close this issue because I don't think there is anything that the Go project should do here. Please comment if you disagree.

@golang golang locked and limited conversation to collaborators Sep 14, 2018

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
You can’t perform that action at this time.