You probably shouldn't be using the WhiteHat Aviator browser if you’re concerned about security and privacy.

I want to be clear that I’m very happy people can take Chromium and build something better on top of it. That’s a big part of why Chromium is open source—to encourage community contributions and third-party innovation. And I want to commend WhiteHat on releasing the source to their fork, because that allows more honest discussion and the potential for shared innovations. But I also feel compelled to stress that building a safe browser is a very hard thing to do, which is why Chrome Security has roughly 30 full-time members and Chrome Privacy has another dozen or so themselves—and none of us are ever short on work.

So, with that in mind I want to explain why I was so concerned after a fairly cursory inspection of the Aviator source code release. First, we found that the overwhelming majority of changes were superficial and branding related, but done so in a way that seriously complicates the process of tracking upstream security fixes. That's why Aviator is perennially at least two major releases behind Chrome, and ships with dozens of publicly disclosed vulnerabilities that are already fixed in the stable Chrome release. Had these branding changes been made more carefully, this simply wouldn't be a problem and Aviator would be able to pull upstream changes and benefit from the security work being done by the Chromium Project.

Unfortunately, the story gets worse when you get to the meat of the relatively small number of technical changes in Aviator. +Tavis Ormandy already tweeted one <>, which is the most trivial RCE bug we found yesterday, but it's important to appreciate that wasn't an isolated issue. The added code doesn’t seem to have been written with a sufficient understanding of how Chrome works, or with adequate regard for security. Take this case <> where explicit debug breaks are disabled for seemingly no reason at all. In Chrome that call is expected to safely terminate sandboxed processes in a whole slew of situations where the process cannot safely recover, but in Aviator all of those cases have now been turned into potentially exploitable vulnerabilities.

After looking at the newly introduced features, it’s also very hard to understand why any of these changes were made so invasively, and at the cost of hindering compatibility with upstream. Because, so far I just don’t see Aviator adding anything that couldn’t be done much more safely and cleanly via the normal extensions APIs, since the bulk of Aviator’s enhancements are actually provided by the already popular Disconnect extension for Chrome <>. And the rest of the changes appear to be covered by changing a handful of well-documented <> default settings. And I should note you can already find detailed reccomendations <> on configuring stock Chrome for the seriously privacy and security concerned user, which strike me as more effective in practice.

In the end, I really hope this criticism is taken constructively, and provides some useful context for people who want to enhance Chrome. I'm always impressed by the size and passion of the Chromium community, and blown away by the number of people who contribute to and build projects on top of our codebase. But at the same time it’s very important that care be taken in those efforts to preserve the safety of end-users, even more so when making such bold claims about security and privacy (particularly given that security is a necessary precondition for privacy). So, it's critical to get the basics right, like following secure coding practices, tracking stable branches for security fixes, and keeping local changes minimally invasive to simplify the maintenance burden.

Added 10 January 2015

WhiteHat made a blog post in reply, but it didn't really clarify the scarier points I raised. So, I'm adding in the text from my comment on this below:

Sadly, that response doesn't address the big concerns that the added code is simply of extremely low quality and littered with fairly trivial security vulnerabilities. And that the pervasive modifications of so much of the code serve no value to the user (e.g. changing internal scheme names from "chrome:" to "aviator:" and stripping attribution from BSD license headers), while making it unreasonably difficult for WhiteHat to ever maintain it. So, even if they fixed all the vulnerabilities they added, I don't see how they could ever keep this up to date against disclosed vulnerabilities already fixed in the stable version of Chrome.

They do have an entirely reasonable point with their example of Chromium not supporting internal network blocking. That's why fixing sure would have been a nice contribution to the Chromium community, and would have given them access to open source contributors who understand the code and could have helped them develop a proper implementation that didn't introduce trivial RCE. That's not to claim their only option was to work with the Chromium community, but it would seem like a far better option than the irredeemable code they ended up with.

Overall though, I'm just increasingly disappointed that the response continues abdicating responsibility for such sweeping and inaccurate claims (e.g. "the most secure browser online"), or that making the source public somehow absolves them of that responsibility. As someone who has spent years working in open source every day, I know that posting a public repo does not suddenly create a community. A community grows from engagement and contribution, usually over a period of years. Nothing like that is even being hinted at here; rather the behavior here is the kind of thing just gives open source a bad name.

#chrome   #security  
Shared publiclyView activity