Security Issues using Homebrew or Macports, malicious binary insertion

[Ryan Schmidt]

On Nov 6, 2018, at 09:14, Nicholas Papadonis wrote:

> This article goes into depth on how Homebrew opens OSX to a number of security issues. I'm curious if a security expert could comment if similar vulnerabilities exist with Macports.
> 
> One vulnerability is a malicious program acquiring the administrators password. The attack is opened up when Homebrew modifies /usr/local/bin permissions for r/w by a non-root user. This permission change allows an installed brew app to modify other binaries in this path, for instance sudo. Homebrew defaults the path prefix as follows /usr/local/bin:/usr/bin and therefore the malicious binary can take advantage of this by inserting another fake malicious binary.
> 
> The article is as follows:
> https://applehelpwriter.com/2018/03/21/how-homebrew-invites-users-to-get-pwned/
> More vulnerabilities here:
> https://hackerone.com/homebrew/
> 
> The author claims that Macports is more secure because the installed explicitly uses root privilege during package installation.
> 
> Are there any security experts out there that can comment on the security impact of using Homebrew and Macports? To be more secure should one use all their Unix applications in a emulated Linux VirtualBox session?
> 
> Thanks for any insight you may have.


Installing MacPorts using the installer package posted on our web page requires an administrator password, and the files and directories it installs are owned by root, meaning nobody but an administrator can change them. It also creates a normal unprivileged user account called "macports" for MacPorts to use later.

Using MacPorts as installed in this way also requires an administrator password. The files MacPorts ports install are usually owned by root, though individual ports can make their own decisions about that. For example, a database server port might create a special user account to be used by the database server when it's running, and it might install an empty directory where the files that the database server will write can live, and the owner of that directory would be set to that new user account.

When you invoke the "port" command with "sudo" and provide your administrator password, MacPorts switches to the unprivileged "macports" user. At that point it no longer has root privileges so even if a malicious portfile were committed that tried to do this, it could not modify files outside of its build directory. MacPorts elevates back to root privileges when doing something that requires root access, for example for the final step that actually installs the files into the /opt/local prefix.

It is possible to build MacPorts from source configured not to use root access, and if you do that, you don't get the above protections. We don't recommend doing this.

MacPorts keeps track of what files each port installs and does not permit one port to overwrite another port's files (unless the user requests this by using the -f flag, so the user should refrain from habitually using this flag).