Security Issues using Homebrew or Macports, malicious binary insertion

[Nicholas Papadonis]

Do you know if there is a select group that reviews source changes to the
installer package and ports installer?  This seems like a good entry point
to slip in malicious binaries as root.  Therefore I'm curious if there is a
good security lock on it.

Thanks again for your help

On Tue, Nov 6, 2018 at 12:54 PM Ryan Schmidt <ryandesign at macports.org>
wrote:

>
>
> 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).
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.macports.org/pipermail/macports-users/attachments/20181106/7c041e9e/attachment.html>