Security Issues using Homebrew, malicious insertion


(Nick Papadonis) #1

This article goes into depth on how Homebrew opens OSX to a number of security issues. One is a malicious program acquiring the administrators password. Most of it stems in Homebrew’s modification of /usr/local/bin for r/w by a non-root user. By doing this, an installed brew app can modify other binaries in this path, for instance sudo. Homebrew defaults it’s path to prefix /usr/local/bin:/usr/bin and therefore the malicious app can take advantage of this.

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 while we are discussing this)? Should I just use all my Unix applications in a emulated VirtualBox session with Linux to truly be secure?

Thanks for any insight you may have.

Nicholas


(Mike McQuaid) #2

This is called “responsible disclosure”; we have security experts who check Homebrew for issues and they are published once they are resolved. This is also done by Google, Microsoft, Facebook and Apple.

I cannot comment on MacPorts. I can say with Homebrew I am acquaintances with multiple people who have been targeted by nation-state level adversaries and run Homebrew in it’s default configuration. The vast majority of people I know who do security work for a living and development on macOS run Homebrew in it’s default configuration. I’d suggest their security requirements are higher than yours but take from any of that what you will.


(Joel) #3

The difference between those people and the average user is probably that they expect to be attacked while the average user doesn’t.

As you can see from the above, /usr/local/bin occurs before the other directories, which means it gets searched first.

Wouldn’t this be solved by simply putting /usr/local/bin somewhere after /usr/bin. This would prevent this kind of attack wouldn’t it?


(Mike McQuaid) #4

That’s true but it’s not relevant to the argument at hand. Stating this is an invitation for Homebrew users to get owned is a massive, unfair exaggeration and I’ve pointed out the implicit disagreement by extremely knowledgable actors in the security space.

It would avoid specifically things being written to /usr/local/bin but not this kind of attack unless you ensured you never had any user-writable directory before system directories. This would mean you cannot use e.g. rbenv and you cannot ever use Homebrew to install newer versions of system-provided tools.


(Joel) #5

Fair point.

True, I had not thought of that. But installing newer versions of system-provided tools would still be possible by creating a not user-writeable directory and then symlinking the tools into there. But at this point it’s getting a bit complicated.

An entry in the documentation about the security of homebrew might be a good idea.


(Mike McQuaid) #6

If I have write access to your user (which is the suggested attack above) I just modify your shell startup scripts to change your PATH to whatever I choose.

If I have write access as your user outside of a sandbox and you’re trying to trick someone into running something in their terminal there is a near-endless ways of attacking that user. I’d question why getting sudo access in a post-SIP macOS is more valuable than being able to e.g. read/write/delete all your local emails, documents, etc.

See “Why does Homebrew prefer I install to /usr/local ?” and “Why does Homebrew say sudo is bad?”" in https://docs.brew.sh/FAQ.

I don’t really want to get into a back and forth on our FAQ about this; it’s not really a FAQ as much as a “frequently stated reason Homebrew sucks” in which case if you really, really care don’t use /usr/local (a bad, unsupported idea) or MacPorts which uses a different security model.


(Nick Papadonis) #7

Here is a response from macports folks on their functionality:
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).


(Nick Papadonis) #8

One more response. I would be interested in a homebrew developers response on this one.

RESPONSE

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.


(Mike McQuaid) #9

While this is correct this assumes the MacPorts or other approaches are more secure than Homebrew’s and I do not agree with this conclusion. There is not a consensus amongst the wider macOS-using security community that MacPorts is inherently more secure than Homebrew or that Homebrew is inherently insecure. Regardless, if you’d rather use MacPorts because you perceive their model to be more secure: please go ahead.