Executable code loaded over an insecure channel (High Risk)

[TheRook]

When downloading executable code from SourceForge brew choose to use an insecure channel (http), which is vulnerable to a man-in-the-middle attack. The transmission of executable code over HTTP is extremely hazardous as it leads to remote code execution. The following insecure behavior was observed:

~> brew install Caskroom/cask/filezilla
==> brew cask install Caskroom/cask/filezilla
==> Downloading http://downloads.sourceforge.net/project/filezilla/FileZilla_Client/3.10.3/FileZilla_3.10.3_macosx-x86.app.tar.bz2

Brew was installed on one our high security systems. A vulnerability which leads to remote code execution on this system is unacceptable, and we are forced to uninstall brew until this high risk issue is addressed.

[TheRook]

HTTP/2 uses encryption by default. Downloading packages over HTTP is an information leakage vulnerability, as it discloses what packages are installed and their exact version. The widespread use of HTTP by caskroom, is very concerning, and this not acceptable behavior.

[phinze]

Thanks for reporting this. We should definitely be using HTTPS where possible.

To ease your concerns a bit, for casks with versioned URLs we do checksum verification of the download, so even if the transport mechanism is insecure, the final contents of the payload are checked.

I'll do a bit of testing and see if we can do a sweep of HTTP -> HTTPS changes wherever the remote servers support it.

[TheRook]

@phinze The root my concern is that Caskroom is not use HTTPS whenever possible. The majority of HTTP links have a valid HTTPS counterpart, but there is no system in place to ensure that these formula are abiding by some basic level of security and privacy.

The link provided in the Filezilla formula:
http://downloads.sourceforge.net/project/filezilla/FileZilla_Client/3.10.3/FileZilla_3.10.3_macosx-x86.app.tar.bz2

Can be access from HTTPS:
https://downloads.sourceforge.net/project/filezilla/FileZilla_Client/3.10.3/FileZilla_3.10.3_macosx-x86.app.tar.bz2

[phinze]

Yep, totally agreed. If HTTPS is possible we should prefer it. We'll get the existing URLs cleaned up and add this to our Cask review policies.

[TheRook]

Thank you.

[vitorgalvao]

@TheRook Rest assured, we take security seriously. For any other links you find that have secure alternatives, please feel free to submit correcting PRs or opening other issues.

As a side note, if you look for it you’ll find some casks that had https urls that were changed to http. This is made when https links do nothing more that redirect to their http counterparts, as having the https there when it isn’t actually secure would be disingenuous.

The issue of how to warn users is being covered in #1824. Perhaps we could expand on this a bit more: #10380.

[tapeinosyne]

We already prefer HTTPS.

To my knowledge, SourceForge does not offer HTTPS; it merely redirects all HTTPS requests to HTTP.

E.g. see curl -I https://downloads.sourceforge.net/project/filezilla/FileZilla_Client/3.10.3/FileZilla_3.10.3_macosx-x86.app.tar.bz2

[radeksimko]

@ndr-qef True, but I agree with @TheRook that HTTPS should be always preferred as long as the URL (even after x redirects) gives you the package. If the vendor redirects from HTTPS to HTTP, we can treat that as their own fault and if anyone in the future will complain about that, we can point to the vendor. We may eventually end up having a stronger voice for HTTP->301->HTTPS.

We (as Cask maintainers) should be just doing as much as we can.

[vitorgalvao]

As stated in my post (and times before, when I’ve made http to https changes), if an https url simply points to an http one, then we should use the http one. It's disingenuous to do otherwise.

Having https links that do not work as such will make it seem like the landscape is better than it actually is, when we want the exact opposite. If it is the vendors’ fault for not providing https (and there is nothing we can do about that unless ask), that should be made visible, not obscured. Users should be able to tell just by catting a cask.

[radeksimko]

@vitorgalvao Hmm, you're kinda of right... it pleasantly surprises me how you can often come up with a good explanation and persuade me... 👍 :)

Nonetheless I still believe we have got many casks that have http:// and could have https:// (and those are cases where HTTPS does not redirect to HTTP).

[radeksimko]

I'm thinking about creating a semi-automated check for all URLs that would go through all casks with url 'http:// and do following:

• take the url
• change http to https
• run curl -I (HEAD)
• if there is HTTP 200 OK, suggest that as a candidate
• if there's HTTP 3xx and the resulting Location is still HTTPS, suggest that as a candidate

I previously thought it could be part of brew cask audit but I'm afraid there will be many false positives, so it should just probably stay somewhere in ./develop/bin/ as a simple way of checking these things for maintainers or anyone else.

[vitorgalvao]

@radeksimko Automating that check sounds great, and our best option. All for it.

[phinze]

Great discussion here, and very good point @vitorgalvao about why to avoid HTTPS -> HTTP redirecting URLs. I was originally in the "we should prefer HTTPS in all cases so that we automatically upgrade to the secure pathway when upstream vendors do", but I see now that it does a disservice to our users to pretend like things are secure when they are not.

I was actually going down a road very similar to the one @radeksimko described with the check above (enhancing the brew cask _checkurl codepath).

Another possible approach that just came to mind:

• Always prefer HTTPS URLs in casks
• Show the user a warning when an HTTPS URL redirects to an HTTP URL

Pros:

• Less manual polling for upgradable URLs
• Promotes to all users the bad security practice of HTTPS -> HTTP redirects, potentially putting more pressure on vendors
• Because the messaging happens at runtime, less overhead in explaining the policy via rejections of "http" -> "https" PRs

Cons:

• Static analysis of Casks is potentially misleading about how many are truly secure.

What do you think?

[vitorgalvao]

I still think there’s a lot of value to having urls show as http for users catting a cask, but I like your idea of showing the warning at install time better in the sense of making more people aware of the importance of https. Especially if we implement #10380, I think I like your solution better.

[TheRook]

I like this discussion. I agree that the user should be aware of security problems, but it would be best if it "just worked". Brew doesn't have the financial backing to host it's own mirrors, and i'm not sure if moving insecure package sources to GitHub is practical.

I think the most negligent provider is SourceForge. What if we convert generic sourceforge download URLs into a HTTPS URL that points to a mirror which supports HTTPS. For example, it looks like the University of Kent (an official mirror) provides a proper transport layer:

https://www.mirrorservice.org/sites/download.sourceforge.net/

Having three or more HTTPS mirrors would solve the problem. Brew could randomly choose a safe mirror, and if its down, go to the next one.

[vitorgalvao]

@TheRook As you understand, we can’t host mirrors ourselves as that is not only highly impractical, but down right impossible to manage for a team of volunteers our size¹. We can’t even keep everything we already have up-to-date (and we get a ton of contributions), let alone managing everything in mirrors. Homebrew-cask isn’t our full-time job, and even it it were, that’d still be hard as hell.

Not everyone (read, almost no one) is using homebrew-cask on such a sensitive computer as your team is, and the logistics alone aren’t worth it at all in the bigger picture. That is why it can’t “just work”. We don’t have the resources (human or technical) or the support (in the end, we’re still just a third-party tool), and unless we became a commercial product (which I don’t see happening) or get what we need in some other way (yes, including no-strings-attached consistent financial aid to host everything), that simply won’t happen.

But that was not necessarily your suggestion, so lets not focus on that. Your proposal of using third party mirrors would mean users of homebrew-cask would have to trust us (and the mirrors) blindly for every cask, and I believe we pride ourselves in having easily auditable casks (we don’t even accept stuff we have mild doubts about). That would also put a huge burden on maintainers to check all of these mirrors as trustworthy. The one you point to, if it is indeed official, would in theory be a good resource. I say in theory because it doesn’t really seem to be an up-to-date mirror — I’ve checked a bunch of packages that don’t have the latest (or even recente) versions, like xampp.

All that said, there is a great solution for your problem. It’s easy to do and can be implemented now: homebrew taps. We support them in the same way homebrew does, and they work just as well. If you make a tap for your team, and manage the secure mirrors, you’ll be able to use it as expected, and can be completely sure you’re getting the right software via secure channels.

---

¹ Making the team bigger ins’t a solution either, as we need to check a lot of things regarding submissions, and it takes time for new maintainers to get the hang of what they are.

[TheRook]

... or more accurately i'm suggesting a feature that is both easy to implement, and "cuts to chase".

So when you access "downloads.sourceforce.net" you are redirected to a url like http://kent.dl.sourceforge.net. ALL SourceForge mirrors are CNAME records that point to a "3rd party provider", such as the University of Kent. SourceForge relies upon 3rd parties for all of their heavy lifting, and my proposal is that we limit the mirrors to a secure subset, thus fixing SourceForge's vulnerable infrastructure for them.

[radeksimko]

@TheRook A few notes:

Brew doesn't have ...

(Home)brew and (Homebrew) Cask / Brewcask are two separate projects each with different team of maintainers. Brewcask uses the Homebrew's infrastructure quite extensively, but actually tries to separate the code as much as possible due to a different nature of this project and some legacy artefacts in the codebase. Either way without Homebrew, Brewcask probably wouldn't exist or it would take much more effort to do certain things.

... the financial backing to host it's own mirrors ...

Homebrew is actually mostly Github's baby (but obviously wouldn't exist too long without an extensive community support). They are aware of this problem too and after they received decent financial support via Kickstarter, they used that money to pay for brew-bot (Jenkins instances) & to build "bottles"

brew-test-bot & bottles

This effectively solves many problems for Homebrew:

• archive (bottle) freshly built directly from source without having to rely on any 3rd party maintainer
• stability (bottles are available even when the vendor's server is down or if vendor decides to move the package to a different path)
• transparency in packaging
• installation repeatability & testability
• HTTPS even when the source code comes from HTTP

Is that applicable for Brewcask?

The difference and issue I see in brewcask is that we're dealing with binaries and there isn't many casks that are actually open-source and allow us to make our own builds. More importantly many packages are provided under many different licenses. Saving these binaries to a different server may eventually break some licenses and would need to be discussed thoroughly first. Keep in mind that we already hide all the license agreements & forms away from user by automating installation.

We are already separating casks where the link is behind registration wall as that means more effort for maintainers and most likely licensing troubles.

I obviously don't want to bother user with licenses during the automated installation (I'd be the first to complain about that), but we need to find the balance between respecting the vendor and not obstructing the user.

@vitorgalvao

Not everyone (read, almost no one) is using homebrew-cask on such a sensitive computer as your team is, and the logistics alone aren’t worth it at all in the bigger picture.

I'm not sure where do you get the certainty as we don't collect any data about users nor installations? Ain't saying we should guarantee anything, but I think we should aim for the state when nobody will have to be worried too much about using that project on a sensitive computer.

As you understand, we can’t host mirrors ourselves as that is not only highly impractical, but down right impossible to manage for a team of volunteers our size...

As mentioned above, it doesn't have to mean extra effort for humans - look at the concept of bottles which are practically fully automated. Generally I believe that there are things that can be automated and could take the load off the maintainers, so they can focus more on making Brewcask core better.

All that said, there is a great solution for your problem. It’s easy to do and can be implemented now: homebrew taps.

Agreed completely, if I was to use Cask today in an "enterprise" company, I'd probably run my own tap internally, the same would apply to Homebrew too.

[TheRook]

Privacy must never be a luxury that is reserved for the few, this is clearly a problem that will not exist in the future. The more pressure we apply now, the sooner this issue will be addressed for everyone.

[vitorgalvao]

@radeksimko You are very right, and I shouldn’t have worded it with such certainty. I’m following the notion that the majority of our users are individuals, not teams, but that is only a deduction from the types of issues we get. I do not indeed have hard numbers, and should’ve worded that accordingly.

Regarding keeping everything up-to-date, you’re right there as well. If we had the technical resources to host the mirrors, we’d indeed have the capabilities to automate the tasks. We’d still have stuff not up-to-date, but it wouldn’t be worse.

@TheRook

Security must never be a luxury that is reserved for the few

No one is advocating that. But we can’t do what we can’t do. We need to do the best we can with the resources we have, and that does not include the capability for hosting mirrors.

this is clearly a problem that will not exist in the future

Lets hope so, but I highly doubt it’ll disappear completely any time soon, unless something amazing happens, to make it trivial.

The more pressure we apply now

Getting around the lack of https support from some vendors by providing https links ourselves (via mirrors or otherwise) isn’t applying pressure — quite the contrary. Why would vendors care about implementing https natively, if we’d be doing it for them? That’d make the problem worse, not better.

[TheRook]

I'm carefully applying pressure here, because Caskroom is the source of privacy violations in my day to day life.

On Sun, Apr 5, 2015 at 10:48 AM, Vítor Galvão [email protected]
wrote:

@radeksimko https://github.com/radeksimko You are very right, and I
shouldn’t have worded it with such certainty. I’m following the notion that
the majority of our users are individuals, not teams, but that is only a
deduction from the types of issues we get. I do not indeed have hard
numbers, and should’ve worded that accordingly.

Regarding keeping everything up-to-date, you’re right there as well. If we
had the technical resources to host the mirrors, we’d indeed have the
capabilities to automate the tasks. We’d still have stuff not up-to-date,
but it wouldn’t be worse.

@TheRook https://github.com/TheRook

Security must never be a luxury that is reserved for the few

No one is advocating that. But we can’t do what we can’t do. We need to do
the best we can with the resources we have, and that does not include the
capability for hosting mirrors.

this is clearly a problem that will not exist in the future

Lets hope so, but I highly doubt it’ll disappear completely any time soon,
unless something amazing happens, to make it trivial
https://letsencrypt.org/.

The more pressure we apply now

Getting around the lack of https support from some vendors by providing
https links ourselves (via mirrors or otherwise) isn’t applying pressure — quite
the contrary. Why would vendors care about implementing https natively,
if we’d be doing it for them? That’d make the problem worse, not better.

—
Reply to this email directly or view it on GitHub
#10377 (comment)
.

[vitorgalvao]

I'm carefully applying pressure here

We appreciate the concern and the gesture. As you can see, all of us maintainers care for security as well. However, once again, there’re limitations to what we can do. Unfortunately, you’re pressuring the wrong place: we can’t do much about it. However, the sooner we can implement something like #10380, the sooner the problem will be mitigated.

In addition, I’ll remind you of taps, that not only solve your problem right now, they’re way better than you could ever expect from us (who’s to say there won’t be a breach on one of the official vendors, where the binaries will be replaced by something harmful?).

The suggestion to limit sourceforge downloads to a specific subset is a good one, and I urge you to open an issue to start the discussion on the viability of that solution, as well as keeping track of its progress (since this issue already has a lot of parallel ideas).

[TheRook]

@vitorgalvao A few SourceForge mirror support HTTPS. Please consider this option before stating that there is no solution.

[vitorgalvao]

Please consider this option before stating that there is no solution.

Please read my comment, as I clearly address that in the last paragraph.

[MikeMcQuaid]

... or more accurately i'm suggesting a feature that is both easy to implement, and "cuts to chase".

I hope the Caskroom folks don't mind me (a Homebrew maintainer) diving in here but we've had a similar issue from @TheRook in our repository and I'd like to reiterate what I've said there: please do not tell volunteers working on a project in their spare time for free that they should do something because you want them to. Additionally, please do not say a solution is "easy" unless you are willing to write, test and submit it yourself as a pull-request.

[radeksimko]

@MikeMcQuaid 👍
I guess this is the thread you're talking about Homebrew/legacy-homebrew#38311

[MikeMcQuaid]

@radeksimko Yup.

[phinze]

Thanks @MikeMcQuaid <3

As I think we've all stated pretty clearly, every one of us cares deeply about privacy and security, and we're committed to doing the best we can to make Cask reflect those ideals.

The difficulty comes in dealing with the limits of our project. The raw truth of it is that we're quite limited on development resources - especially when it comes to core development. Any potential solutions we decide to pursue must take in mind those limitations.

I think there's been a lot of valuable conversation here, but I believe we have reached the point of diminishing returns on pure conversation. I'm going to close this thread and ask that we open specific, actionable enhancement issues to further this initiative (several of which have already been spun off). That way we can consider and discuss the specifics of any enhancements in a focused way.