Have a security researcher audit Homebrew
MikeMcQuaid opened this issue · 20 comments
@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.
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.
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.
Where might I read about the binary package plans?
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
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.
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.
@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.
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).
We removed it from the one-line install on the homepage so it could be done in the script too.
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.
The curl on the home page is still using the less specific curl command, isn't it?
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 :)
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.
The main brew.sh website still does not have an HTTPS certificate (I raised this issue last year). I would like to again volunteer to help purchase one and set it up for you, if possible. The reason is that very important people at Google, TOR, and other organizations are using the awesome homebrew project. But, the initial installation instructions are displayed over the website using HTTP, without a security certificate. This means that if the FIVE EYES or other adversaries wanted to compromise the machine of someone first installing homebrew on their computer, the HTTP stream could be modified to change the instructions displayed to the user. Perhaps the FIVE EYES would alter the github URL to something similar but under their control like...
ruby -e "$(curl -fsSL https://raw.githubusercontent.com/Homebrew2/install/master/install)"
...instead of the actual real location like...
ruby -e "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/master/install)"
The change may be so slight like that so many people don't notice. Of course, only high valued targets would like be exploited this way. But, the impact could be devastating. If it were a Google employee or TOR core developer working on a major open source project, the developer would be compromised and easily able to be manipulated into inserting a backdoor into the software they are developing, without ever even knowing they got compromised. Adding a HTTPS certificate can make that harder, although still not fool-proof, as the FIVE EYES can easily create CA certificates that work in the browser and then DNS redirect the victim to a doppelganger site under their control, again with the same compromising outcome. However, HTTPS pinning might make this less feasible.
Updating this conversation, I see @ioerror has raised similar concerns. Last year we discussed over email that you were potentially going to implement CloudFlare in front of http://brew.sh. We should also disable basic HTTP and / or ensure HSTS with CA preload pinning, so that even the first connect to brew.sh domain will be encrypted. Let me know if any progress was made toward that goal or if you need assistance. I also audited all the homebrew recipes for lack of sha256 / sha1 checks, etc and only found ~10 that were concerning. Like was pointed out earlier, plaintext hg, svn, cvs, and git were to blame there. Also realize that since all this code is open source, well positioned and well funded entities may also have the ability to create HASH COLLISIONS on the open source code binary builds, if they understand the build parameters / hardware / etc. This is why Tor signs their builds rather than using just a hash, since advanced attackers can take the open source code, implement the same build process, and brute force a hash that runs bad code, but still hashes to the same sum value. This is more an issue with SHA1 currently than SHA256 of course, but moving all recipes to SHA256 / SHA512 / SHA-3 -- or SKEIN -- at least and GPG checking (if supported by the release team) is preferable...
I'd like to help, so let me know! :)
The main brew.sh website still does not have an HTTPS certificate (I raised this issue last year). I would like to again volunteer to help purchase one and set it up for you, if possible.
We looked into this, extensively. There's a whole broad discussion in an issue some months ago. Essentially, we can't do it and remain on Github pages. So then there's hosting costs, and configuration, and SSL costs to deal with, and it adds up quickly. Maintaining a server to serve a single website is a pretty tedious maintenance process, from experience.
Adding a HTTPS certificate can make that harder
Meh. The entire CA system is screwed. Superfish, Fake certificates issued to Google domains that remain in place for weeks, an individual/group was issued a cert covering Microsoft Software Updates despite not proving they worked for Microsoft, not to mention huge CAs controlled essentially by countries' governments.
Last year we discussed over email that you were potentially going to implement CloudFlare in front of http://brew.sh.
Cloudflare blocked us on this avenue.
create HASH COLLISIONS
There's nothing provably completely broken about SHA1, yet, but we've recently switched to SHA256 by default for all new formulae and are working on migrating existing ones regardless. All bottles produced by Homebrew from last week forwards are SHA256 checked rather than SHA1.
GPG checking (if supported by the release team) is preferable
Also recently discussed, at least for Homebrew's binary packages, and potentially long-term for others as well. There's ongoing discussion about Homebrew publishing a GPG key for security communications and signing all the binary packages with it.
The usage of the system OpenSSL has also been completely deprecated in the past ~6 months, and formula authors get big, ugly red warnings to switch to Homebrew's OpenSSL if a formulae taps OpenSSL. Homebrew also removed SSLv2 from OpenSSL, and discussions were had on removing SSLv3 once Debian Jessie lands stable and does the same. SSLv2 and SSLv3 were both removed from PolarSSL.
Progress is being made on a lot of issues, but I'll shut up, the maintainers grow tired of hearing my virtual voice enough as it is 😅.
@kristian-hermansen I'm working on getting SSL on the homepage but the combination of GitHub Pages, CloudFlare and DNSimple are making it more complicated than I want it to be. I'm not convinced the homepage is particularly exploitable as people who care about security aren't going to be piping in random Ruby scripts without inspecting the URL.
I don't think GPG is a silver bullet as it relies on the secrecy of the private key. Your checksums exploit requires not just brute-forcing SHA-1 (or, as @DomT4 pointed out, increasingly SHA-256) and additionally hacking servers and replacing their checksums.
The most helpful thing you can do is submit pull-requests to improve things. I've personal biases against members of the security member whose "help" in the past has involved telling us what we are doing wrong without writing any code to fix the problems. As a result I'm not really interested in having lots of discussion about this: let's work together on PRs. Thanks!
Does homebrew still download some packages through insecure connection?
In the log, I could see for example these lines, this implies aften-0.0.8.tar.bz2 is downloaded through insecure connection?
==> Installing avidemux dependency: aften
==> Downloading https://downloads.sourceforge.net/aften/aften-0.0.8.tar.bz2
==> Downloading from: http://softlayer-ams.dl.sourceforge.net/project/aften/aften/0.0.8/aften-0.0.8.tar.bz2
Also, can sourceforge be considered as trusted source after its drama with account stealing?
Does homebrew still download some packages through insecure connection?
Yes.
In the log, I could see for example these lines, this implies aften-0.0.8.tar.bz2 is downloaded through insecure connection?
If you wish to avoid this please set HOMEBREW_NO_INSECURE_REDIRECT in your environment.
Also, can sourceforge be considered as trusted source after its drama with account stealing?
Unless they have found vulnerabilities in sha256 which they are secretly exploiting: yes.
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.