dp-golang Go installation could be owned by wrong user

Vulnerability

In dp-golang prior to version 1.2.7, when Puppet runs as root and installs a Go tarball for macOS (versions 1.4.3 through 1.21rc3 inclusive, or the bootstrap archives go1.4-bootstrap-20170518.tar.gz or go1.4-bootstrap-20170531.tar.gz), the tar command by default preserves the ownership of entries in the archive. These specific tarballs contain files owned by non-root users (e.g., gopher or UID 501). As a result, the owner and group parameters specified in the Puppet manifest are ignored for files within the archive, leaving them owned by the tarball's original user [1][2][3].

Exploitation

An attacker does not need network access to exploit this vulnerability directly. The flaw is present during the initial installation or reinstallation of a Go distribution by Puppet on a macOS system where Puppet runs as root and the affected Go tarball is used. A non-root user on the system who can access the installed Go files (e.g., the user whose UID matches the archive's owner) could modify those files. No additional authentication or user interaction beyond the normal Puppet run is required [2][3].

Impact

If the Go installation files (including the go compiler binary) are owned by a non-root user, that user can modify them. In the worst case, the compiler can be tampered with to inject vulnerabilities into any compiled Go code. This could compromise other users or systems that subsequently run Go programs built with the compromised compiler, potentially leading to privilege escalation or code execution in a broader context [3].

Mitigation

Update to dp-golang version 1.2.7, released concurrently with this advisory. Version 1.2.7 adds an exec resource that checks the ownership of every file in the Go installation directory and recreates the installation if any file has the wrong owner or group. Additionally, extract flags --no-same-owner and --no-same-permissions are now used to ensure files are created with the Puppet-specified user and group. As a workaround, administrators can manually chown the Go directory to the correct owner and group, but this does not guarantee the files have not already been tampered with [1][2][3].