I am presenting at the SINFO conference today. Here are some links as “further reading” for my presentation.
With the important 2.0 milestone I decided to give my Easy Passwords project a more meaningful name. So now it is called PfP: Pain-free Passwords and even has its own website. And that’s the only thing most people will notice, because the most important changes in this release are well-hidden: the crypto powering the extension got an important upgrade. First of all, the PBKDF2 algorithm for generating passwords was dumped in favor of scrypt which is more resistant to brute-force attacks. Also, all metadata written by PfP as well as backups are encrypted now, so that they won’t even leak information about the websites used. Both changes required much consideration and took a while to implement, but now I am way more confident about the crypto than I was back when Easy Passwords 1.0 was released. Finally, there is now an online version compiled from the same source code as the extensions and having mostly the same functionality (yes, usability isn’t really great yet, the user interface wasn’t meant for this use case).
Now that the hard stuff is out of the way, what’s next? The plan for the next release is publishing PfP for Microsoft Edge (it’s working already but I need to figure out the packaging), adding sync functionality (all encrypted just like the backups, so that in theory any service where you can upload files could be used) and importing backups created with a different master password (important as a migration path when you change your master password). After that I want to look into creating an Android client as well as a Node-based command line interface. These new clients had to be pushed back because they are most useful with sync functionality available.
Once upon a time, Google dared to experiment with HTTPS encryption for their search instead of allowing all search data to go unencrypted through the wire. For this experiment, they created a new subdomain: encrypted.google.com was the address where your could get some extra privacy. What some people apparently didn’t notice: the experiment was successful, and Google rolled out HTTPS encryption to all of their domains. I don’t know why encrypted.google.com is still around, but there doesn’t seem to be anything special about it any more. Which doesn’t stop some people from imagining that there is.
This server was overdue for a migration to new hardware, and I used this opportunity to make its setup reproducible by basing it on Docker containers. This allowed me to test things locally, setting everything up on the real server was only a matter of one hour then. Some issues I didn’t recognize locally however, most importantly Docker’s weird IPv6 support. Everything worked just fine when the server was accessed via IPv4, accessing it via an IPv6 address caused connections to hang however. I hit this issue with Docker 1.13.1 originally, updating to Docker 17.12 didn’t change anything. Figuring this out took me quite a while, so I want to sum up my findings here.
First, it is important to know that Docker currently has two entirely different mechanisms implementing published ports. The default is the userland proxy, which is an application listening to a port and forwarding any incoming traffic to the respective container. The downside of this solution is: the proxy needs to open a new connection to the container, which means that the container will no longer see the remote address of the real client but merely the proxy’s address. This might be acceptable for some applications, but if your web server runs inside a container for example it needs to log real remote addresses.
After twelve years of working on Adblock Plus, the time seems right for me to take a break. The project’s dependence on me has been on the decline for quite a while already. Six years ago we founded eyeo, a company that would put the former hobby project on a more solid foundation. Two years ago Felix Dahlke took over the CTO role from me. And a little more than a month ago we launched the new Adblock Plus 3.0 for Firefox based on the Web Extensions framework. As damaging as this move inevitably was for our extension’s quality and reputation, it had a positive side effect: our original Adblock Plus for Firefox codebase is now legacy code, not to be worked on. Consequently, my Firefox expertise is barely required any more; this was one of the last areas where replacing me would have been problematic.
So I am taking all of 2018 off. It’s not merely about being tired of working on the same project. I also noticed that I’ve grown irrationally attached to XUL and Gecko, as I’ve accumulated lots of knowledge in that area over the years and helped many others learn as well. Consequently, while I see Mozilla’s motivation for their rushed Web Extensions move, I cannot feel positive about it. This isn’t a good prerequisite when staying in touch with Mozilla is part of the job description.
Recently, I reported a security issue in the new Firefox Screenshots feature (fixed in Firefox 56). This issue is remarkable for a number of reasons. First of all, the vulnerable code was running within the Web Extensions sandbox, meaning that it didn’t have full privileges like regular Firefox code. This code was also well-designed, with security aspects taken into consideration. In fact, what I found were multiple minor flaws, each of them pretty harmless. And yet, in combination these flaws were sufficient for Mozilla to assign security impact “high” to my bug report (only barely, but still). Finally, I think that these flaws only existed due to shortcomings of the Web Extensions platform, something that should be a concern given that most extensions based on it are not well-designed.
The Firefox Screenshots feature was introduced in Firefox 55 and allows users to easily take a screenshot of a web page or some part of it and upload it to a web service. All uploaded screenshots are public but you have to know the URL. Technically, this feature is really a browser extension that is integrated into Firefox. And when I looked at this extension, I immediately noticed a potential weakness: when you click its toolbar button, the extension needs to show you some user interface to select a website part and actually take the screenshot. And it will inject that user interface into the webpage. So a malicious webpage could in theory manipulate that user interface.
I’ve been increasingly using Bugcrowd lately, a platform that manages security bug bounty programs for its clients and allows security researchers to contribute to a number of such programs easily. Previously, I’ve mostly reported security issues in Mozilla and Google products. Both companies manage their bug bounty programs themselves and are very invested in security, so Bugcrowd came as a considerable culture shock.
First of all, it appears that many companies consider bug bounty programs an alternative to building solid in-house security expertise. They will patch whatever bugs are reported, but they don’t seem to draw any conclusions about the deficiencies in their security architecture. Eventually, even the most insecure application will have enough patches applied that finding new issues takes too much effort for the monetary rewards offered. At that point, almost no new reports will be coming in and for the management it’s “mission accomplished” I guess. Sadly, with security being an afterthought the product remains inherently insecure, even the smallest change could potentially open new security holes.
Almost exactly a year ago I wrote a blog post explaining how permission prompts are a particularly problematic area for a functioning extension ecosystem. While at this point it was already clear that Firefox would show some kind of permission prompt, I hoped that Mozilla would put more thought into it than Chrome did. Unfortunately, this didn’t quite happen. In fact, as I now experienced, the permission prompt in Firefox turned out significantly worse than the one in Chrome.
Two days ago I released a new version of my Google search link fix extension. I finally got to turning that “run on all websites” permission into a list of specific domains, with all of 193 Google domains. And the backlash came immediately, in form of this review (translated from Russian):
I’ve finally released Easy Passwords as a Web Extension (not yet through AMO review at the time of writing), so that it can continue working after Firefox 57. To be precise, this is an intermediate step, a hybrid extension meant to migrate data out of the Add-on SDK into the Web Extension part. But all the functionality is in the Web Extension part already, and the data migration part is tiny. Why did it take me so long? After all, Easy Passwords was created when Mozilla’s Web Extensions plan was already announced. So I was designing the extension with Web Extensions in mind, which is why it could be converted without any functionality changes now. Also, Easy Passwords has been available for Chrome for a while already.
The trouble was mostly the immaturity of the Web Extensions platform, which is why I chose to base the extension on the Add-on SDK initially (hey, Mozilla used to promise continued support for the Add-on SDK, so it looked like the best choice back then). Even now I had to fight a bunch of bugs before things were working as expected. Writing to clipboard is weird enough in Chrome, but in Firefox there is also a bug preventing you from doing so in the background page. Checking whether one of the extension’s own pages is open? Expect this to fail, fixed only very recently. Presenting the user with a file download dialog? Not without hacks. And then there are some strange keyboard focus issues that I didn’t even file a bug for yet.
Emscripten allows compiling C++ code to JavaScript. It is an interesting approach allowing porting large applications (games) and libraries (crypto) to the web relatively easily. It also promises better performance and memory usage for some scenarios (something we are currently looking into for Adblock Plus core). These beneficial effects largely stem from the fact that the “memory” Emscripten-compiled applications work with is a large uniform typed array. The side-effect is that buffer overflows, use-after-free bugs and similar memory corruption mistakes are introduced to JavaScript that was previously safe from them. But are these really security-relevant?
Worst-case scenario are obviously memory corruption bugs that can be misused in order to execute arbitrary code. At the first glance, this don’t seem to be possible here — even with Emscripten the code is still running inside the JavaScript sandbox and cannot escape. In particular, it can only corrupt data but not change any code because code is kept separately from the array serving as “memory” to the application. Then again, native applications usually cannot modify code either due to protection mechanisms of modern processors. So memory corruption bugs are typically abused by manipulating function pointers such as those found on the stack.