Security Issues using Homebrew or Macports, malicious binary insertion

[Nicholas Papadonis]

I appreciate the detailed description.

Do you know anything about the process to integrate new source code, review
changes that are Mac specific, mark branches stable, build and release?  Do
particular users have privileged access to be part of this process?

I suspect this is an issue with any open source project, however am curious
how MacPorts itself ensures the code from the project makes it to release
as original as possible.  I hope these are the right questions to ask form
a security standpoint.

Thanks

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/1d989b72/attachment.html>