An Update on WebKit Security Updates

One year ago, I wrote a blog post about WebKit security updates that attracted a fair amount of attention at the time. For a full understanding of the situation, you really have to read the whole thing, but the most important point was that, while WebKitGTK+ — one of the two WebKit ports present in Linux distributions — was regularly releasing upstream security updates, most Linux distributions were ignoring the updates, leaving users vulnerable to various security bugs, mainly of the remote code execution variety. At the time of that blog post, only Arch Linux and Fedora were regularly releasing WebKitGTK+ updates, and Fedora had only very recently begun doing so comprehensively.

Progress report!

So how have things changed in the past year? The best way to see this is to look at the versions of WebKitGTK+ in currently-supported distributions. The latest version of WebKitGTK+ is 2.14.3, which fixes 13 known security issues present in 2.14.2. Do users of the most popular Linux operating systems have the fixes?

  • Fedora users are good. Both Fedora 24 and Fedora 25 have the latest version, 2.14.3.
  • If you use Arch, you know you always have the latest stuff.
  • Ubuntu users rejoice: 2.14.3 updates have been released to users of both Ubuntu 16.04 and 16.10. I’m very  pleased that Ubuntu has decided to take my advice and make an exception to its usual stable release update policy to ensure its users have a secure version of WebKit. I can’t give Ubuntu an A grade here because the updates tend to lag behind upstream by several months, but slow updates are much better than no updates, so this is undoubtedly a huge improvement. (Anyway, it’s hardly a bad idea to be cautious when releasing a big update with high regression potential, as is unfortunately the case with even stable WebKit updates.) But if you use the still-supported Ubuntu 14.04 or 12.04, be aware that these versions of Ubuntu cannot ever update WebKit, as it would require a switch to WebKit2, a major API change.
  • Debian does not update WebKit as a matter of policy. The latest release, Debian 8.7, is still shipping WebKitGTK+ 2.6.2. I count 184 known vulnerabilities affecting it, though that’s an overcount as we did not exclude some Mac-specific security issues from the 2015 security advisories. (Shipping ancient WebKit is not just a security problem, but a user experience problem too. Actually attempting to browse the web with WebKitGTK+ 2.6.2 is quite painful due to bugs that were fixed years ago, so please don’t try to pretend it’s “stable.”) Note that a secure version of WebKitGTK+ is available for those in the know via the backports repository, but this does no good for users who trust Debian to provide them with security updates by default without requiring difficult configuration. Debian testing users also currently have the latest 2.14.3, but you will need to switch to Debian unstable to get security updates for the foreseeable future, as testing is about to freeze.
  • For openSUSE users, only Tumbleweed has the latest version of WebKit. The current stable release, Leap 42.2, ships with WebKitGTK+ 2.12.5, which is coincidentally affected by exactly 42 known vulnerabilities. (I swear I am not making this up.) The previous stable release, Leap 42.1, originally released with WebKitGTK+ 2.8.5 and later updated to 2.10.7, but never past that. It is affected by 65 known vulnerabilities. (Note: I have to disclose that I told openSUSE I’d try to help out with that update, but never actually did. Sorry!) openSUSE has it a bit harder than other distros because it has decided to use SUSE Linux Enterprise as the source for its GCC package, meaning it’s stuck on GCC 4.8 for the foreseeable future, while WebKit requires GCC 4.9. Still, this is only a build-time requirement; it’s not as if it would be impossible to build with Clang instead, or a custom version of GCC. I would expect WebKit updates to be provided to both currently-supported Leap releases.
  • Gentoo has the latest version of WebKitGTK+, but only in testing. The latest version marked stable is 2.12.5, so this is a serious problem if you’re following Gentoo’s stable channel.
  • Mageia has been updating WebKit and released a couple security advisories for Mageia 5, but it seems to be stuck on 2.12.4, which is disappointing, especially since 2.12.5 is a fairly small update. The problem here does not seem to be lack of upstream release monitoring, but rather lack of manpower to prepare the updates, which is a typical problem for small distros.
  • The enterprise distros from Red Hat, Oracle, and SUSE do not provide any WebKit security updates. They suffer from the same problem as Ubuntu’s old LTS releases: the WebKit2 API change  makes updating impossible. See my previous blog post if you want to learn more about that. (SUSE actually does have WebKitGTK+ 2.12.5 as well, but… yeah, 42.)

So results are clearly mixed. Some distros are clearly doing well, and others are struggling, and Debian is Debian. Still, the situation on the whole seems to be much better than it was one year ago. Most importantly, Ubuntu’s decision to start updating WebKitGTK+ means the vast majority of Linux users are now receiving updates. Thanks Ubuntu!

To arrive at the above vulnerability totals, I just counted up the CVEs listed in WebKitGTK+ Security Advisories, so please do double-check my counting if you want. The upstream security advisories themselves are worth mentioning, as we have only been releasing these for two years now, and the first year was pretty rough when we lost our original security contact at Apple shortly after releasing the first advisory: you can see there were only two advisories in all of 2015, and the second one was huge as a result of that. But 2016 seems to have gone decently well. WebKitGTK+ has normally been releasing most security fixes even before Apple does, though the actual advisories and a few remaining fixes normally lag behind Apple by roughly a month or so. Big thanks to my colleagues at Igalia who handle this work.

Challenges ahead

There are still some pretty big problems remaining!

First of all, the distributions that still aren’t releasing regular WebKit updates should start doing so.

Next, we have to do something about QtWebKit, the other big WebKit port for Linux, which stopped receiving security updates in 2013 after the Qt developers decided to abandon the project. The good news is that Konstantin Tokarev has been working on a QtWebKit fork based on WebKitGTK+ 2.12, which is almost (but not quite yet) ready for use in distributions. I hope we are able to switch to use his project as the new upstream for QtWebKit in Fedora 26, and I’d encourage other distros to follow along. WebKitGTK+ 2.12 does still suffer from those 42 vulnerabilities, but this will be a big improvement nevertheless and an important stepping stone for a subsequent release based on the latest version of WebKitGTK+. (Yes, QtWebKit will be a downstream of WebKitGTK+. No, it will not use GTK+. It will work out fine!)

It’s also time to get rid of the old WebKitGTK+ 2.4 (“WebKit1”), which all distributions currently parallel-install alongside modern WebKitGTK+ (“WebKit2”). It’s very unfortunate that a large number of applications still depend on WebKitGTK+ 2.4 — I count 41 such packages in Fedora — but this old version of WebKit is affected by over 200 known vulnerabilities and really has to go sooner rather than later. We’ve agreed to remove WebKitGTK+ 2.4 and its dependencies from Fedora rawhide right after Fedora 26 is branched next month, so they will no longer be present in Fedora 27 (targeted for release in November). That’s bad for you if you use any of the affected applications, but fortunately most of the remaining unported applications are not very important or well-known; the most notable ones that are unlikely to be ported in time are GnuCash (which won’t make our deadline) and Empathy (which is ported in git master, but is not currently in a  releasable state; help wanted!). I encourage other distributions to follow our lead here in setting a deadline for removal. The alternative is to leave WebKitGTK+ 2.4 around until no more applications are using it. Distros that opt for this approach should be prepared to be stuck with it for the next 10 years or so, as the remaining applications are realistically not likely to be ported so long as zombie WebKitGTK+ 2.4 remains available.

These are surmountable problems, but they require action by downstream distributions. No doubt some distributions will be more successful than others, but hopefully many distributions will be able to fix these problems in 2017. We shall see!

19 Replies to “An Update on WebKit Security Updates”

  1. I wonder how many other packages Debian just neglects with backports like this. It’s scary to think of the security implications.

      1. Yeah, I actually quoted that policy in my original blog post. It’s accurate except for the statement “Additionally, library interdependencies make it impossible to update to newer upstream releases.” That was surely true in the past, but we’ve been very strict about dependency bumps for many years now to avoid precisely this problem.

  2. Nothing will change until there will be LTS releases of WebKit with bugfixes being relarly backported. It is a way all actively developed software is getting up-to-date in non-rolling linux distros.

    1. Sorry, community-supported LTS releases of WebKit are not practical and not going to happen.

      (Edit: Added “community-supported.” We could try doing this if some company wants to pay for it.)

      1. Then stop complaining that WebkitGTK is insecure. LTS distributions can’t just pull the latest upstream versions. That may work on your desktop, but not in enterprise environments where software *must* work reliably.

        If you don’t believe me, talk to people from any larger corporate like SAP or IBM and they’ll tell you the same thing.

        1. I’m not complaining that WebKitGTK+ is insecure.

          The unfortunately reality is that backporting even only critical security fixes involves relatively high risk of introducing regressions, more so the older your branch is, due to the high number of security issues and the high rate of refactoring and code churn in WebKit that makes it harder to backport commits as time goes on.

          So if you can’t accept any regressions, you have to choose between either not using a web engine or never updating your web engine and living with the vulnerabilities. The later might be acceptable for some irresponsible companies (notably embedded systems vendors), but I suspect responsible companies would prefer a middle of the road approach, of doing the best they can with an LTS branch and fixing regressions as they are introduced via backports gone wrong. That requires some investment, though. I’m sure our sales team would love to hear from any companies interested in this style of product.

          1. I think going forward there needs to some kind of distinction between full WebKit support and low-risk usage. I imagine for something like GnuCash or Empathy, they just need a HTML rendering engine for simple stuff. So with some guidelines or code to make sure the inputs are escaped/safe, they shouldn’t have be involved when there’s a security update, unless it is for very basic stuff.

        2. If enterprise environments and large corporates require this, then they should pay someone to do it, instead of complaining that the volunteers giving them free software are occasionally taking time off to eat and sleep.

  3. Please make Webkit2gtk compile and work on Windows.

    We use Webkit1gtk in our product and i works on Linux, Mac and Windows. We are unable to switch to Webkit2gtk since it is not working on Windows.

    1. Unfortunately Windows support would be a big project. 100% (or nearly 100%) of WebKit developers primarily use either macOS or Linux, so nobody is currently interested in Windows support for WebKit2. So it’s not going to happen unless some company is interested in sponsoring it. That would have to include both the initial work to support Windows, and also long-term maintenance as we wouldn’t want to add support for Windows if it’s just going to be left to rot.

      If you work for a company that would be interested in paying for this, please do get in touch. Otherwise, my recommendation is unfortunately to stop using WebKitGTK+, at least for your Windows product.

      1. That is sad to hear, that Windows has no focus.

        We do not have the option to stop using Webkitgtk+ for now, there is really no alternative and it would be a big undertaking.

        We are a company with interest in Webkitgtk+, may not have the financial to fund such a project. What are we talking about here ?

        We don’t use Webkitgtk+ to access the internet, only to show information inside the application. So it’s not really a security issue for us. So sticking with Webkitgtk 2.4.11 is fine for now.

        1. If your application does not process any untrusted input, then you can safely use 2.14.11 forever, so long as you’re aware that it’s been unmaintained since 2014.

          Cost for Windows support… I guess high tens of thousands of euros. I can put you in touch with our sales team if you want.

  4. Sounds great. But there is only a GTK3 version, right?
    There are still many “complete” GTK2 projects whose owners don’t want to deal with GTK3’s constant API changes.

    1. Don’t take me wrong. I am very glad you are doing something about it. I acknowledge that you cannot possibly keep up a GTK2 port. Please in return acknowledge that this situation still harms finished apps in favor of unfinished software. Thanks.

      1. Hi, it’s true, we don’t support GTK+ 2 anymore, and that’s very bad for GTK+ 2 apps like GnuCash (among many others).

        The good news for you is that GTK+ 3 is frozen now, and changes that break applications are no longer allowed. If your application works properly in GTK+ 3.22.0 but is broken by a change in a later version of GTK+ 3, you can file a bug and it will be reverted. So far, I don’t think this has happened to anybody. So now would be a great time to port to GTK+ 3. I’m optimistic that the new GTK+ version numbers policy and stability guarantees will avoid this GTK+ 3 stability issue repeating itself with future major versions of GTK+, so that’s good.

        The bad news, besides that porting to GTK+ 3 will probably be a lot of work, is that we’re not going to have the resources to maintain the GTK+ 3 version forever, either. I don’t know when that will be. Certainly not anytime soon, as we don’t even support GTK+ 4 yet. But sooner or later — I’ll blindly guess 3-5 years from now, but I don’t know — we’ll be removing support for GTK+ 3. If keeping up with GTK+ upgrades is going to be a problem for your application, then unfortunately my only recommendation is to not use WebKitGTK+. :(

Comments are closed.