Our Audit of Homebrew

I'm the author of this post and one of the people behind the audit; happy to answer questions about it.

If you're having trouble finding the audit itself (it's linked indirectly), I'm linking a copy here as well[1].

[1]: https://github.com/trailofbits/publications/blob/eb9344f2261...

Excellent work - a methodical review like this is exactly what I’ve been looking for in these sorts of open source solutions.

I know it’s not the focus of a code review like this, but I’m interested to hear your views on the general supply chain lifecycle problems inherent to open-source package management platforms. Principally, are vetting processes appropriate to ensure that new formulas refer to the correct source? How does the user gain confidence that their brew update is still referencing a trusted source? What happens when a domain is taken over? How quickly can the team respond to untrusted sources from formulas?

I know these aren’t all Homebrew problems to solve, but they’re important ecosystem considerations.

(These problems also exist in the winget and choco platforms, but less so in commercially supported repos like apt and yum. For me, and many other admins, they are a major concern when it comes to the Windows Store.)

Edit: lastly, in case the homebrew team are watching: an npm-style vulnerability notice would be awesome

Before moving to Nix, I was using MacPorts since Homebrew had some...eccentric behavior at the time (didn't work with multi-user setups, owned your /usr/local, lots of "works on my machine" problems from auto-updating and lack of version control, ...). One thing that has always felt insecure about Homebrew to me was the ability to use GitHub (not Git) URLs as ad-hoc packages. I wonder if that is how TOB-BREW-13 worked? That feature of Homebrew has always sounded like a security incident waiting to happen.

In any case, I'd be interested in seeing an audit of Nix on Mac OS. Especially if there is a flaw in how `nix develop` and related commands work.

I peeked at the sandbox escape bug and its associated fix: https://github.com/Homebrew/brew/pull/17700/commits/f4e5e0c7.... Is this…correct? Like, this is to prevent it from being interpolated into a sandbox profile and messing things up. How confident are we about this list of characters?

I ditched `brew` for `nix` a while back and while the TUI could be more end-user-friendly (to the point that I wrote a wrapper called "ixnay" just so I could do "ixnay install <packagename>" as easily as with brew, https://github.com/pmarreck/ixnay), the overall guarantees make it worth it.

I am a bit surprised this did not highlight major low skill attack surface in Homebrew as compared to almost all Linux and *BSD package managers: Supply chain integrity.

Homebrew maintainers mostly do not sign commits/packages, do not sign reviews/merges, do not verify author/reviewer sigs at compile time, do not reproduce builds in separately controlled CI, do not enforce hardware 2FA on Github.

Every user of brew is only as secure as whichever of hundreds of brew maintainers has the worst opsec today.

Also since dependabot automatically makes commits, you could get a malicious commit into an external project you control, wait for dependabot to make a commit to homebrew to upgrade it, then merge it yourself (as becoming a homebrew maintainer has almost no vetting, just fix a few easy bugs)

You could also just take over one of the expired email domains of a maintainer and send a password reset email to yourself and take over an account of someone on vacation or hiatus.

Can likely get thousands of companies compromised before anyone notices.

Honestly I would never allow Brew on any company machines I have authority over. It is giving hundreds of randos, (and anyone that takes advantage of their poor opsec) the ability to execute any code on user systems.

Major Linux package managers do not go nearly far enough with things like review signing, but most at -least- do author-level package signing, human review, and independent reproduction for most packages.

Given how many high value targets like corporate sysadmins allow brew on their computers, Brew is on track to overshadow Crowdstrike any day now for most harm caused by insufficient supply chain management.

If macs supported PKGBUILDs like Pacman with a similar level of performance and there were correctly maintained packages for core programs I'd feel like using a mac would have a lot less compromises for convenience.

Homebrew is great and the formulae are maintained really well but the simplicity of PKGBUILDS, the fast syncing, and lack of cognitive burden of recalling multiple arguments/flags for package managers make me wish pacman just worked on macs.

The main attack vector IMHO is the simple fact that one can sneak in new packages with malicious intent by simply contributing a new formula. The team of maintainers is too small to audit all of the newly contributed formulae. I'm suprised that this attack vector wasn't part of the audit.

There's a bunch of TOB-BREW-n listed - are those like CVE numbers just for this project?

Edit: Oh, it's "Trail Of Bits - homeBREW". But probably still yes.

I’m a bit puzzled by the wording of this blog post, because it says you’ve worked with Homebrew to do this audit, but your name sounds familiar to me, and indeed if we check Homebrew’s README [1]:

> Homebrew's maintainers are […long list of names…] William Woodruff […]

[1]: https://github.com/Homebrew/brew

Is there any reason this is not mentioned in the blog post? I don’t think it would make a difference, but just to clarify things.

Well done! And thank you to the Open Tech Fund for sponsoring work to protect everyone who uses Homebrew.

There's an interesting alternative to Homebrew: Devbox

It abstracts Nix in a way you don't have to know or learn anything about the Nix language.

I wrote a few words on how I use it instead of Homebrew [1].

[1] https://mootoday.com/blog/i-replaced-homebrew-with-devbox

https://mootoday.com/blog/i-replaced-homebrew-with-devbox

Kinda off topic, but when I see a project or an article use brew on Linux instead of their native package manager or something like flatpak I generally assume the author has very limited knowledge about Linux and I can ignore this project/article.

Were the reported issues all addressed by the Homebrew maintainers or are any still unmitigated?

Any idea how much impact the audit has and/or applies to Workbrew[0], their new business-oriented MDM-manageable package tool?

[0] https://workbrew.com/

Nowadays even Windows has a package manager (https://en.wikipedia.org/wiki/Windows_Package_Manager). Why does Apple/Mac OS X not develop something similar?

Great that there are people looking into this. I wonder if there would be similar findings were they to perform an audit on MacPorts or the Nix package manager.

A while back I was trying to understand why Homebrew requires pre-built executables to be installed into /home/linuxbrew. I asked about it here[0]. This requirement basically makes it impossible to use homebrew to quickly install programs on systems where you don't have root, or at least have homebrew already configured (not sure if that would solve it but I assume so).

They pointed me to an example program that would break if not run this way: Facebook's Watchman[1].

It bizarrely (to me) has hard coded paths compiled into it, which force you to run it from specific directories.

Would love to understand what's going on here and why you would ever make software work this way. I feel I'm missing a fairly obvious Chesterton's Fence.

[0]: https://github.com/orgs/Homebrew/discussions/5371

[1]: https://facebook.github.io/watchman/docs/install#prebuilt-bi...

The amount of value returned to the Apple ecosystem through brew is remarkable and while this post makes me even more in awe of the care that goes towards the community, I'm sad that one of the richest companies in the world isn't giving more back.

With so many other package managers available, I often wish something else was the de facto package manager on macOS. Something like pkgsrc, which follows conventions much better and is thereby much easier to manage.

MacPorts is always waiting for you with more packages, a better design, and Jordan Hubbard’s history with BSD/Apple :)

Apple should have been the one funding the audit.

I’m still good on MacPorts. Seems I’m alone these days. Works fine for me.

  > Since 2012, Trail of Bits has helped secure some of the world’s most targeted organizations and products. We combine high-­end security research with a real­ world attacker mentality to reduce risk and fortify code.

It's interesting that I don't see any analysis referencing OpenBSD (either as a product or as an alternative to something else they have done research on).

Not surprised to see some problems. Still sad to see security take a backseat as opposed to convenience.