Security Issues using Homebrew or Macports, malicious binary insertion
nick.papadonis.ml at gmail.com
Tue Nov 6 22:28:48 UTC 2018
I notice source is located at:
Is there any specific way for one to reconcile the binaries Macports is
installing to the source code maintained by the project? Branch, tag,
On Tue, Nov 6, 2018 at 12:54 PM Ryan Schmidt <ryandesign at macports.org>
> 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:
> > 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
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the macports-users