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: Go compiled binaries with ldflags "-s -w" reveal too much information #19226

Closed
sanbornm opened this issue Feb 21, 2017 · 10 comments

Comments

Projects
None yet
7 participants
@sanbornm
Copy link

commented Feb 21, 2017

Please answer these questions before submitting your issue. Thanks!

What version of Go are you using (go version)?

go version go1.8 darwin/amd64

What operating system and processor architecture are you using (go env)?

Darwin amd64

What did you do?

go build -ldflags "-s -w" <-- trying to strip/remove information from distributed binary

strings binaryname

What did you expect to see?

I expected to not see all vendored library paths and path names used to compile the binary file.

What did you see instead?

If you run strings on any Go binary you can see all vendored packages used as well as the path of all packages used to compile the binary. This is not ideal in a commercial setting and probably useful to find/use exploits in a compiled binary.

@ianlancetaylor ianlancetaylor changed the title Go compiled binaries with ldflags "-s -w" reveal too much information cmd/compile: Go compiled binaries with ldflags "-s -w" reveal too much information Feb 21, 2017

@ianlancetaylor

This comment has been minimized.

Copy link
Contributor

commented Feb 21, 2017

Stripping package paths would break runtime.Caller and reflect.Type.PkgPath. I don't think there is any reasonable way that we can do it.

@dongweigogo

This comment has been minimized.

Copy link

commented Feb 22, 2017

I found that too, and it makes me unhappy
@ianlancetaylor

Stripping package paths would break runtime.Caller and reflect.Type.PkgPath. I don't think there is any reasonable way that we can do it.

is it possible to set an argument or something as a choice to switch those on or off for a distributed version?

@minux

This comment has been minimized.

Copy link
Member

commented Feb 22, 2017

@sanbornm

This comment has been minimized.

Copy link
Author

commented Feb 22, 2017

Stripping the package paths to prevent exploits is security by obscurity.
People can do pattern matching on the instructions to match a given package
just as easily.

Sure, but the current behavior shows personal information like the full URI including Github/Bitbucket username and names of internal packages.

@slrz

This comment has been minimized.

Copy link

commented Feb 22, 2017

The username part seems like a red herring. It's just the package's import path, no?

@as

This comment has been minimized.

Copy link
Contributor

commented Feb 22, 2017

I think the point is that the import path can contain confidential information. Not every Go project is open source, some use it to displace C++ in their organization and are surprised when strip has different semantics. Security-sensitive projects strip binaries to protect intellectual property as part of a defense in depth approach.

@ianlancetaylor

This comment has been minimized.

Copy link
Contributor

commented Feb 22, 2017

People concerned about import paths may find the compiler's -trimpath option to be useful.

I don't think there is anything we can actually do here, so I'm going to close this issue. If anybody has a concrete proposal for a change here, please comment or open a new issue. (I don't think that "drop all package path information" can work, as it would break too many libraries.)

@dongweigogo

This comment has been minimized.

Copy link

commented Feb 23, 2017

@ianlancetaylor
May I ask how to pass the -trimpath to Go toolchain?

@ianlancetaylor

This comment has been minimized.

Copy link
Contributor

commented Feb 23, 2017

go build -gcflags=-trimpath=x/y
@dongweigogo

This comment has been minimized.

Copy link

commented Feb 24, 2017

@ianlancetaylor
thanks. I thought the -trimpath was a asm flag

@golang golang locked and limited conversation to collaborators Feb 24, 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.