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).
