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.
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
/sbinWhat 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.
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/homebrewTo 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 --installNavigate 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 packagesConclusion
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 Support Server. 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 ;).
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.
I mean… yes, but that would also require sudo so kinda defeats the purpose.
Oh I see, comments are not being published. So why did I even bother typing. ..
Comments do get published, we just need to manually greenlight them for spam first
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. 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.
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.
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.
I do my best to be as pragmatic as possible and never engage in mundane software religion wars (which given your written hyperbolism seems to be the case here). However I do like conversations that help improve security of systems and this is why controversy may be good in this case and I’ll take a moment to respond.
I was looking for good information about what were the attack vectors on homebrew, and stumbled on your article, the following kind of click baited me
> However, I’ve never seen a binary package manager that creates more of a security problem having it than not having it.
I would like to explain why what you see as a problem doesn’t create any new attack surface, what you see as an issue is just how most UNIX systems shells work and in this case how MacOS is handling the default path for user provided binaries. Calling it a major security flaw is an overstatement if not a fallacy, and doesn’t help anyone secure their system better.
Before I get into the technical details, here are a few things that should be considered beforehand:
1. The PATH variable evaluation order: Depending on the order in which a path is listed in this variable, the folder will be checked first or last (respectively in order of listing)
2. For multi-user system, the shared homebrew folder, the user who installed homebrew has read/write to it (only the user who installed it or an admin)
3. For homebrew binaries to be exposed to all the users, either the system admin would have to add its path to /etc/paths, /etc/paths.d, /etc/profile, /etc/bashrc or /etc/zshrc or individual users would have to add it to their .bashrc, .bash_profile, .zshrc,…
4. By default, permissions on either /usr/local/ or /usr/local/ don’t allow any user to write, which means only an admin (sudoer) can install it
Now let’s look at what arguments you use after your statement, “Ok, here’s where the vulnerability comes in”:
1. Imagine if someone wanted to make a fake sudo command…
2. a malicious program can place a script called “sudo” in …
3. Homebrew creates an administrator security bypass when it is installed.
With the initial clarification and the summary of your points, let’s look at what would be the threat model here and what is missing for your statement to actually be a valid one:
1. Homebrew needs to be installed by an admin (a quick look at the homebrew install script, including previous versions would clarify this)
2. By extension, the homebrew folder permissions would be tied to the installer (admin)
3. Either an admin or users, would have to add homebrew binaries to their PATH, making sure they prepend it to their list of paths
4. The admin (homebrew install user) needs to install an untrusted software
5. The untrusted software would target homebrew specifically, to create a fake sudo for other users (admin users or users with specific sudo limitation only)
6. A user would run the sudo command and get pwnd
The thing is, as a malicious program would have to target the hombrew install user which is also an admin, we could just skip steps 3, 5 and 6 and have the malicious software change the path to a local folder with a fake sudo (/home/user/.ssh/sudo) and change the path order locally through (.bashrc, .zshrc,…)
So based on the above, a malicious program doesn’t need homebrew to elevate it’s privileges, because to change homebrew’s binaries, you would need someone with sudo access already (homebrew install user)… So macports doesn’t add any security here.
However, there are other attack vectors to both homebrew and macports and I have been looking more at how do they do add software to the default package list, for example by preferring projects that follow https://github.com/ossf/scorecard
Writing a good technical article takes time, because you need to confirm all your assumption, and do some research for things you didn’t account for before reasoning on these elements. And perhaps the most important of all, be the worse critic of your conclusions, just to make sure they stand. When I read your article, I felt that you were upset at the time of the writing and I can’t but wonder what happened before you wrote this article.
I’m looking forward to a revised article or a follow-up with a more rigorous intent.
The hyperlink for the ‘Info Toast Support Server’ has a typo:
– https://app.element.io/#/room/#info-toast:infotoast.ems.hos
should be:
https://app.element.io/#/room/#info-toast:infotoast.ems.host
xoxo
Oh my thank you!