5

This question already has an answer here:

I read (here and here) that Homebrew (the Unix package manager) is a significant Mac security risk. An attack is allowed because Homebrew makes /usr/local/bin writable without root user privilege, which allows another Homebrew process to write a malicious process into this directory tree. The /usr/local/bin tree is by default prefixed before /usr/bin in the path for the shell. As such, an attacker could inject a malicious binary to change the clock or steal an administrator's password (malicious sudo for instance).

Is there anyone out there aware of these vulnerabilities? Does anyone have a better method of gaining access to critical Unix commands without impacting the security of the end user's terminal (MacBook w/ OSX for instance)? Do you use Macports which relies on a package manager that installs using root privilege to /opt? Do you perform all your Unix shell work in an emulator like Virtual Box or VMWare?

I know there are many security holes starting with manufacturing and as soon a software app is installed. I'm very curious on best practices from a security expert on this.

UPDATE 2018-11-07

I checked with the macports mailing list and received quick detailed replies. Unfortunately, no response with details on functionality from the Homebrew forum. At this point, I suspect macports has better security functionality. There can always be a hole somewhere and to be truly secure, I will consider installing these open source applications in a self contained emulated container. For instance using VirtualBox, VMWare or Parallels. This way, if there is a security issue, it will be contained and not expose access to the Mac Keychain or other critical data.

UPDATE received from macports mailing list

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

Another post

It is also to be noted that homebrew can not suddenly change itself to deliver this degree of security without a fairly complete rehash of the way it works, and most/many/all of it's "advantages" of installing in /usr/local that have served to make it popular would then be totally lost, and most likely many/most/all of it's formulae would need to be rewritten to accommodate this change. Many of them at present assume things are found automatically in /usr/local .

homebrew has been popular because it's "easy" -- it's files in /usr/local are found without intervention by any compiler or shell. However, that does not come without costs.

MacPorts requires more work to specifically include certain include paths, library paths, and executable paths -- but that comes with some knowledge of what you're actually getting, and the security of knowing that it can't be messed with without your permission.

marked as duplicate by Tom K., schroeder Nov 6 '18 at 16:31

This question has been asked before and already has an answer. If those answers do not fully address your question, please ask a new question.

  • This isn't really a new vulnerability though. Since processes running as your user already has write access to the user's shell rc file (e.g. ~/.bashrc), a malicious or buggy process could already shadow critical commands that way (e.g. echo 'alias sudo=/malicious/fake-sudo' >> ~/.bashrc). brew's security (like any pre-vetted package manager) comes mainly from the formula maintainer defining the hashes on downloaded packages. – Lie Ryan Nov 7 '18 at 22:41
0

You can change your path order in /etc/paths to prevent such malicious behaviour. However $PATH could be overrided in shell script (like .bash_profile or .zshrc) so check/change them too.

Regarding Macports - I prefer to run untrusted software in a userspace with minimal privileges, so Homebrew is more suitable.

Regarding Unix shell - just build a chain of trust, i.e. use trusted shell in trusted terminal. I've additionally hardened my Mac with Patrick Wardle's tools because they're open-sourced and provide necessary network and system access controls.

Not the answer you're looking for? Browse other questions tagged or ask your own question.