Use -buildmode=pie (Position Independent Code/ Executable)

[jcscottiii]

Go v1.6 brought about the introduction of -buildmode=pie. However, it only is supported by some platforms including: linux/386, linux/amd64, linux/arm, linux/arm64, and linux/ppc64le. Since it is not supported for all, I suspect that is why it is not default. However, it would be nice to support a way to trigger this when building.

https://golang.org/doc/go1.6#compiler

[cf-gitbot]

We have created an issue in Pivotal Tracker to manage this. You can view the current status of your issue at: https://www.pivotaltracker.com/story/show/113966315.

[flavorjones]

Hi @jcscottiii,

Thanks for proposing this feature! I'd like to better understand the advantages of generating PIE code -- can you provide a bit of context around why you think it's better, and what advantages (as specifically as you can) you'll get if the buildpack does this?

[jcscottiii]

Hey @flavorjones!!

Background: PIE / PIC is typically done to thwart exploits originating from buffer overflow. Without the address randomization of PIE / PIC, an attacker's code can smashes the stack and with the knowledge of your app's address layout, can overwrite the return address to a function of method in your code that is something a normal user should never have access to execute.

My background:

• I am by no means a security expert. During my past life of being a C++ developer, I learned about this stuff back then. There could be constructs in Cloud Foundry and / or Go to ignore the need for it.

Why:

• This would be about preemptive security (Go is awesome and secure.. for now).
• I imagine you could harden your stemcell even more with SELinux and restrict it to only allowing PIEs to run.
• Something you'll probably want if there is ever stemcell support for RedHat Linux (which ties into the previous SELinux point)

Current threat to Go: There have not been any reports of stack smashing within Go itself. (However, you can read this)

Potential Target: The vulnerable surface area would be limited to the data in a Warden or Garden container. This includes environment variables which could contain sensitive authentication data.

A Potential (Wild In My Head That Could Be Wrong / Highly Improbable) Scenario:

• A malicious attacker replicates your Cloud Foundry setup and deployment in order to learn the address layout of your Go program.
• A malicious attacker hijacks vendor source code (either via 1) just hiding it within the dependency's git repo. or 2) a redirect when go get drops down into http if https is not available with a man in the middle of attack when trying to pull the dependency code down)
• During execution, they could somehow smash the stack and cause the program to return to a place (because it knows the addresses) that it should not and potential show something bad or just make it crash.

Disadvantage: A common disadvantage is that the executable will take more space and could be slightly slower.

[flavorjones]

This seems like a totally reasonable thing to do. I'll chat with the team about it!

[Dannyzen]

@jcscottiii Thanks for your input! We've included this change into our develop branch. For more information see this commit

[jcscottiii]

@Dannyzen thanks!!

[RochesterinNYC]

Closing this issue as it's in our develop branch and will be made available on the next go-buildpack release. Thanks for bringing this to our attention @jcscottiii

[Dannyzen]

@jcscottiii this has been included in go-buildpack 1.7.4