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

proposal: os/exec: Add ability to limit or prohibit the use of spawning subprocess' #54621

Closed
ecnepsnai opened this issue Aug 23, 2022 · 7 comments

Comments

@ecnepsnai
Copy link

ecnepsnai commented Aug 23, 2022

Background

The os/exec pacakge allows Go applications to spawn subprocesses, which can enable Go applications to interact with other executables on the system. This is a widely used practice, but presents a security risk for the running system.

Should the running application be impacted by a remote code execution vulnerability, the ability to spawn applications on the running system can pose a significant threat.

For example, a recurring trend on other langues like Go is malicious third-party packages that contain cryptocurrency mining malware, or "cryptominers". Typically, these malicious packages don't actually contain the mining code in package itself, but rather code that downloads a malicious binary and runs it, as reported on by Bleeping Computer

Some operating systems provide mechanisms to limit process spawning, such as Security Enhanced Linux (SELinux), or Windows AppLocker, however not all of the supported OS targets of Go offer such features. Additionally, these features can be difficult to configure and are often disabled.

Proposal

As an optional security hardening measure for Go applications, I am proposing that we add the ability to restrict or prohibit the use of spawning subprocesses through os/exec.

In cases where the functionality is disabled, no subprocesses can be spawned through os/exec. However, we could provide an allowlist mechanism where only specific binaries may be executed by their path.

In an application where the developers know there will not be any need for spaning subprocesses, disabling that functionality provides a layer of defence. In the example of malicious packages above, this mechanism would prevent the malicious mining binary from being executed. This should not be seen as a complete defence, but an additional safeguard used in conjuction with others.

This feature should be opt-in so that existing applications are unaffected.

Design

Disabling spawning subprocesses

At build time, set the GOEXECDISABLED=1 environment variable.

Then, any calls to os/exec.Cmd.Start() return an error indicating that the functionality is disabled.

Restrict spwaning subprocesses

At build time, set the GOEXECALLOW="/usr/bin/foo:/usr/bin/bar" environment variable, which takes a colon separated list of files that can be executed by os/exec. If GOEXECDISABLED is specified, it would take precedence over this.

Then, any calls to os/exec.Cmd.Start() return an error if the execuable path is not in the allowlist, otherwise it is executed normally.

@gopherbot gopherbot added this to the Proposal milestone Aug 23, 2022
@ecnepsnai
Copy link
Author

This is my first proposal to go, so please forgive me if I've made a mistake on the process somewhere!

@seankhliao
Copy link
Member

cc @golang/security

@mvdan
Copy link
Member

mvdan commented Aug 23, 2022

How can we possibly restrict this via just os/exec? Presumably I could make the right fork+exec syscalls myself, or copy the bits from os/exec which do this. Or use cgo to instead fork and execute a program from there.

@ianlancetaylor
Copy link
Contributor

There are many ways that a Go program is vulnerable if an attacker is able to force it to execute code determined by the attacker. The os/exec package is just one of many cases. Most obviously, Go programs can make system calls directly using syscall.Syscall, and can easily start programs using syscall.ForkExec.

So my concern would be that this idea, though not in itself terrible, is just a small bandaid that will in the best case do nothing much and in the worst case lead people to believe that there is more security than there actually is.

@ecnepsnai
Copy link
Author

Closing as not technically feasible

@rsc
Copy link
Contributor

rsc commented Mar 29, 2023

This proposal has been added to the active column of the proposals project
and will now be reviewed at the weekly proposal review meetings.
— rsc for the proposal review group

@rsc
Copy link
Contributor

rsc commented Apr 6, 2023

This proposal has been declined as infeasible.
— rsc for the proposal review group

@golang golang locked and limited conversation to collaborators Apr 5, 2024
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

6 participants