Have a security researcher audit Homebrew

[MikeMcQuaid]

@ioerror said he would look into it.

---

Edit: hello me from 8 years ago! Just noticed this issue is linked in a few prominent places so wanted to chime in with a note that Homebrew was audited in 2020 and published a blog post and results about this in 2022. At the time of writing (July 2023): another security audit has begun.

[ioerror]

There are a few different topics that come to mind - from code signing and verification in a given Formula to transport security with SSL pinning.

Basically any Formula has the ability to execute arbitrary code on the user's machine, so any insecurely fetched code on the system will allow the local network to pop a shell - so for an hg repo without https, nearly instant code exec. I pushed a fix for the golang hg --HEAD Formula for this exact reason, actually.

I think there are lots of things to discuss - I'd also suggest that the primary authors of Homebrew look at the Update Framework, https://www.cs.arizona.edu/stork/packagemanagersecurity/ and https://www.cs.arizona.edu/people/jsamuel/papers/samuel-cappos-login-feb09.pdf as well as other related work by Justin Cappos.

[MikeMcQuaid]

Good points, thanks. I'll check these links out. Any thoughts around our binary packages would be good too (we'll roll out a whole bunch more post-Kickstarter).

The arbitrary code execution is one of the reasons we (unlike many package managers) don't use root.

[ioerror]

Where might I read about the binary package plans?

[ioerror]

I was looking at the well know one line install on the home page: ruby -e "$(curl -fsSL https://raw.github.com/mxcl/homebrew/go)" and I think it might be better if it was ruby -e "$(curl --tlsv1 --proto = https -fsSL https://raw.github.com/mxcl/homebrew/go)" as it will prevent downgrades to HTTP and require only TLSv1 (or better, I think).

Also - I think that it is majorly bad news that inside that there is a curl that uses -k when fetching the homebrew master tarball. Is that really required? On OS X 10.8.2 - I don't need -k and it opens my system up to a MITM attack unnecessarily

[MikeMcQuaid]

The binary package plans are probably most public on the Kickstarter. Outside that you can see the implementation of a binary install by doing brew install qt.

[ioerror]

Curl also has an option to pin to a specific CA (--capath) - so it might even be possible to pin to the specific CA that github uses - probably a great improvement over the full CA root store.

[ioerror]

@MikeMcQuaid I'd probably spin up a vm for each build from Jenkins - when someone gets root on your build machine, the outcome will be bad news. I'd probably also try to approach building the way that Gitian suggests - to try to find out when build machines go bad and to catch it before Homebrew users get pwned.

[jacknagel]

I think the -k in the installer script itself is there for Leopard. I would not be opposed to removing it and pointing 10.5 users at a separate installer script (or at tigerbrew).

[MikeMcQuaid]

We removed it from the one-line install on the homepage so it could be done in the script too.

[jacknagel]

9e8ffa9

[camillol]

The arbitrary code execution is one of the reasons we (unlike many package managers) don't use root.

I think the effectiveness of that defense is overstated in the case of Homebrew.

There seems to be a weak underlying assumption in Homebrew that it is going to be used on a Mac with a single user who is an administrator (see the recommended installation instructions & rationale, the fact that formulas like Postgres install under the current user even though they're in a shared prefix, etc.). However, in that case, avoiding root does not really buy you much. A compromised Homebrew can do anything to the current user: steal his data, plant malware (even in places like /Applications, since the user is an administrator), corrupt data, delete files, etc.. We're protecting the shared system part, which can easily be wiped and reinstalled from scratch if necessary, while leaving the user's home completely unprotected, which is where damage can actually hurt.

I think the single-user assumption should be removed. I run as a non-administrator user, personally, and I have previously raised the issue of shared Macs, lab machines etc.. But the security considerations are important, too. In my opinion, the ideal configuration would have Homebrew running as its own user, so that the system will actually prevent it from writing stuff outside the prefix. This means that, if there are two admins on a machine, they will run homebrew as a single homebrew user instead of stepping on each other's toes (with half the cellars owned by user A and half by user B), and there will be no risk of stuff spilling outside of the locations where the homebrew user is allowed to write.

Of course, programs installed by homebrew will still mostly run as whatever user calls them, so this is not a universal protection, but it adds security to the installation process while giving us proper multi-user support.

[ioerror]

The curl on the home page is still using the less specific curl command, isn't it?

[MikeMcQuaid]

Yep but I've showed the necessary people this thread so just closing to decrease our "open" count rather than saying nothing else will be done :)

[camillol]

That's not how issue tracking works.

iPhone�$B$+$iAw?.�(B

02/mar/2013 03:34�$B!"�(BMike McQuaid notifications@github.com �$B$N%a%C%;!<%8�(B:

Yep but I've showed the necessary people this thread so just closing to decrease our "open" count rather than saying nothing else will be done :)

�$B!=�(B
Reply to this email directly or view it on GitHub.