| | | |

Homebrew is a Major Security Flaw — Install MacPorts Instead

I’ve talked before about the various problems with binary package management systems. I have praised BSD’s Ports, where a source code tree allows you to install packages from source with all their dependencies. However, I’ve never seen a binary package manager that creates more of a security problem having it than not having it. That is the case with homebrew security.

The Homebrew Logo

I was trying to find knowledge about how the Homebrew team greenlights their packages to ensure that it’s not filled with viruses. And then I found something disturbing. Very disturbing. A while back, Homebrew ditched the use of sudo in a move that many praised. However, as any experienced UNIX people know, poking holes in the system never ends well.

Homebrew made the installation directory for packages, /usr/local/bin (Yes, I know it’s /opt/local/bin on Apple Silicon), writable to the user that installed Homebrew. This doesn’t seem that bad on the surface until you factor the PATH environment variable in.

The best way I can describe this is that the PATH environment variable includes a list of directories that contain binaries. When the user types in a command, the system looks through each directory until it finds one. It will find the first one that is first in the list of directories. The problem is, Apple put /usr/local/bin first in the PATH environment variable. This is how the directories are listed on a Mac without homebrew or anything that alters the PATH variable.

/opt/local/bin <- Homebrew makes this writable by you on Apple Silicon
/opt/local/sbin
/usr/local/bin <- Homebrew makes this writable by you on Intel Macs
/usr/bin
/bin
/usr/sbin
/sbin

What does this mean for you?

Ok, here’s where the vulnerability comes in. Imagine if someone wanted to make a fake sudo command that grabs your password to elevate itself to administrator. In Macs that have Homebrew installed, as the sudo binary is located in /usr/bin, a malicious program can place a script called “sudo” in /usr/local/bin or /opt/local/bin that takes your password and then uses it to allow a virus to gain administrator access. In other words, Homebrew creates an administrator security bypass when it is installed.

See also  How to Install Wordpress on An Apache Server

What should I do about Homebrew Security?

There is an alternative to Homebrew that, in my opinion, is way better for security. It’s called MacPorts. As Mac is based on BSD, not Linux, Homebrew is a Linux solution to a BSD problem, while MacPorts is a BSD solution to a BSD problem. MacPorts will build packages that you install from source, so everything is tailored to your system configuration. MacPorts also has better support for Apple Silicon.

How do I uninstall Homebrew for better security?

Luckily, Homebrew has made it relatively easy to uninstall. Type in the following command to execute the Homebrew uninstallation script:

/bin/bash -c "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/HEAD/uninstall.sh)"

Once that is done, there are a few other things you may want to do. If you’re on Apple Silicon, you will still need to remove the /opt/homebrew directory from your system. Type:

sudo rm -rf /opt/homebrew

To prevent you from getting spam when starting your Terminal, use nano or vim to open up .zprofile and remove the line that calls the “brew” command.

How to install MacPorts?

MacPorts has made this relatively easy. MacPorts installs more like a traditional Mac app than Homebrew. You can download the .pkg file from the MacPorts site. However, make sure the Xcode command-line developer tools are installed first:

xcode-select --install

Navigate to the MacPorts website and download the installer: https://www.macports.org/install.php.

How to Use MacPorts

You may want to know a few commands you can run to use it.

sudo port selfupdate <- Updates MacPorts and the ports tree

sudo port install <packagename> <- Installs a package

port search <query> <- Searches for ports

port list installed <- Lists installed ports

sudo port uninstall <package> <- Uninstalls a package

sudo port uninstall leaves <- Uninstalls dependencies that are no longer required

sudo port upgrade <package> <- Upgrades a specific outdated package

sudo port upgrade outdated <- Upgrades all outdated packages

Conclusion

If you’re the type that loves hearing about vulnerabilities and loves talking tech, as probably many Homebrew users do, you may be interested in joining the Info Toast Discord: https://discord.gg/rftS5NA. We have a vulnerability watch where we publish the latest vulnerabilities in many popular programs. You can join the vulnerability watch if you love learning about cybersecurity too… or just enjoy being scared ;).

Search Site

Frank

Similar Posts

8 Comments

  1. Interesting. But, installing package with sudo means installer can theoretically write anywhere on the system which is a security risk too, in case if package is tampered with.
    On the other hand, if you have made the system directory user writeable, it means package can install without sudo but only in the directory with changed permissions.
    SO wouldn’t it be the best solution to install without sudo as in Homebrew and revert permissions each time after package is installed? I assume for most users it’s not a big deal to do it manually after installation.

  2. Homebrew maintainer here,

    You got the install location for Apple Silicon wrong multiple times in the article except in the uninstall command. It is in fact /opt/homebrew and this location is not in the PATH variable by default.

    You’re also missing the real problem of the vulnerability you describe. If anyone got unrestricted access to your filesystem nothing stops this malicious actor from adding /some/evil/bin to the PATH variable and putting a malicious sudo binary there. Neither Homebrew nor MacPorts have anything to do with this.

    There are enough reasons to distrust package managers, this isn’t one of them.

    1. 1. The files located in /opt/homebrew are often symlinked to /opt/local/bin
      2. Doesn’t fix the problem for Intel Macs
      3. It’s in the path variable now because Homebrew added it.
      4. You could not only be overwriting the default sudo binary on PATH, but you could also overwrite the physical “sudo” file, making people have to reinstall to recover the system if they catch it.
      5. You’re overwriting the permissions of system files, don’t do it. Even Apple devs yelled at you for this.

      1. So the attacker has access to your local account, and then he:
        1. Creates a local directory ~/malicious-bin
        2. Modifies your ~/.bashrc (or ~/.zshrc) to add ~/malicious-bin as the first item in your PATH
        3. Adds a password hijacking sudo binary to ~/malicious-bin

        Usually steps 1 & 2 are not even required, as it’s quite common to have a ~/bin directory in user’s PATH, and it’s also not unusual for it to be the first item so you can override system commands if needed.

        So how does using MacPorts instead of Homebrew protect you from this? The point is that if someone gains access to your local user account, it’s game over for your user, homebrew installed or not.

        The only problematic thing I can think of here (as long as what you say about user write access to /usr/local/bin is true) is if a malicious actor wants to target account A via a compromised account B. Here it would be problematic if account B would have write access to a directory which is by default in PATH of account A. But as said, this is only really relevant for a multi account system and requires the write access to a common/shared binary directory.

        1. The account doesn’t need to be compromised. If you have another user who shares that computer and is not an administrator, but said non-administrator user either doesn’t know enough to protect themselves from malware, they would like to attempt to gain control of the user, or they are a user that belongs to a daemon such as http which is meant to be protected and sandboxed, that user to gain control of the computer.

Leave a Reply

Your email address will not be published.