Catanzaro: On WebKit security updates

[Posted February 2, 2016 by corbet]

Michael Catanzaro describes the sad state of WebKit security on Linux distributions and the challenges of security support for such a complex package in general. "We regularly receive bug reports from users with very old versions of WebKit, who trust their distributors to handle security for them and might not even realize they are running ancient, unsafe versions of WebKit. I strongly recommend using a distribution that releases WebKitGTK+ updates shortly after they’re released upstream. That is currently only Arch and Fedora. (You can also safely use WebKitGTK+ in Debian testing — except during its long freeze periods — and Debian unstable, and maybe also in openSUSE Tumbleweed. Just be aware that the stable releases of these distributions are currently not receiving our security updates.)" Lots of information here, worth a read for anybody interested in the topic.

Catanzaro: On WebKit security updates

Posted Feb 2, 2016 23:57 UTC (Tue) by flussence (guest, #85566) [Link] (9 responses)

Sounds like Chrome with its frequent updates, aggressive pruning of outdated downloads, and thorough seccomp use is the safest browser on Linux right now.

Fortunately Google's working to level the playing field (in the nuclear sense) by abandoning x86-32 updates *next month*, hooray!

I guess even the world's smartest software engineers couldn't figure out how to rein in its insane build requirements...

Catanzaro: On WebKit security updates

Posted Feb 3, 2016 10:25 UTC (Wed) by ceplm (subscriber, #41334) [Link] (4 responses)

> Sounds like Chrome with its frequent updates, aggressive pruning of outdated downloads, and thorough seccomp use is the safest browser on Linux right now.

Do you like your CoolAid cold or room temperature? What does this article (which is mostly about using WebKit embedded in other apps) have anything to do with the standalone browsers? From the linked article: it doesn't apply to Apple Safari, Mozilla Firefox, and Microsoft stuff, or Chrome.

Catanzaro: On WebKit security updates

Posted Feb 3, 2016 12:10 UTC (Wed) by flussence (guest, #85566) [Link] (3 responses)

Did you read the article or merely skim it for some keywords to attack me with? Here's an actual quote from it:

> If the web engine is sandboxed, then a second type of attack, called a sandbox escape, is needed. This makes it dramatically more difficult to exploit vulnerabilities. Chromium has a top-class Linux sandbox. WebKit does have a Linux sandbox, but it’s not any good, so it’s (rightly) disabled by default. Firefox does not have a sandbox due to major architectural limitations (which Mozilla is working on).

So WebKit's half dozen Linux forks (and by extension, 90% of those Linux standalone browsers you say don't matter, including GNOME's default one) don't even make a token effort to protect against unknown-unknowns. Mozilla's long-term plan seems to be copying Chrome down to the minutiae, which is infinitely better than copying IE6's security model (duck, cover and pray). Google, meanwhile, seem to be doing *all* the work in this field, including pushing seccomp and sandboxing in the first place.

Catanzaro: On WebKit security updates

Posted Feb 3, 2016 12:47 UTC (Wed) by ceplm (subscriber, #41334) [Link] (1 responses)

a) I have already i18n Firefox here, which is one-task-per-tab,
b) this article was completely not about sandboxing

Catanzaro: On WebKit security updates

Posted Feb 3, 2016 13:07 UTC (Wed) by Mannigfaltigkeit (guest, #103163) [Link]

I think you mean e10s. Still, there is considerable work to be done for proper sandboxing, according to https://wiki.mozilla.org/Security/Sandbox

Catanzaro: On WebKit security updates

Posted Feb 3, 2016 14:47 UTC (Wed) by pinkpony (guest, #92373) [Link]

> Google, meanwhile, seem to be doing *all* the work in this field, including pushing seccomp and sandboxing in the first place.

That's a bit of a stretch, on the other hand, it's not a big surprise that a relatively new browser written from scratch would have a much better security model than the one based on 20 years of legacy code. There are weaknesses as well, as mentioned, nobody really likes to build Chromium and push it, meaning many distros don't bother having it at all, some have it in a pretty bad shape, so you get a complete reliance on Google distributing proper (binary only) Chrome updates. Not so easy to say which is more important, once knowingly broken in a certain version and without proper updates, the sandbox isn't that great protection either.

Catanzaro: On WebKit security updates

Posted Feb 3, 2016 15:22 UTC (Wed) by mcatanzaro (subscriber, #93033) [Link] (3 responses)

I don't think security is the most important factor in picking a browser, especially on Linux, and I remain a WebKit partisan. But it's true, neither WebKit nor Firefox are remotely competitive with Chrome in this regard. Chrome has long been the safest browser by far.

Catanzaro: On WebKit security updates

Posted Feb 4, 2016 23:35 UTC (Thu) by flussence (guest, #85566) [Link] (2 responses)

Don't disagree with you there. Security is a nice ideal, but since there's no such thing as perfect security it's not my main priority in choosing a browser.

On the other hand, Chrome is (reluctantly) the main browser on my netbook now. After a long period of browser-hopping I ended up with a list of basic needs — it needs to not take a miserably long amount of time to load pages; to work properly on heavy “Web 2.0” sites; have strong filtering/privacy tools either built in or as extensions; and be installable via package manager (Gentoo's, in this case. I have no problem if it's an overnight job as long as it gets there eventually)

Unfortunately, I had no choice but to cull “FOSS” from the list to meet all the others. I sincerely hope that's not a permanent thing, because as I said initially, Chrome isn't either.

Catanzaro: On WebKit security updates

Posted Feb 5, 2016 15:23 UTC (Fri) by HelloWorld (guest, #56129) [Link] (1 responses)

> Don't disagree with you there. Security is a nice ideal, but since there's no such thing as perfect security it's not my main priority in choosing a browser.
That's like saying that safer sex is a nice ideal, but since there's no such thing as a perfect condom, it's not your main priority in choosing a contraceptive.

And just to be clear: it's perfectly OK to not base your choice of browser on its security. But saying that it's futile doing so because none of them are perfect is a non-sequitur.

Catanzaro: On WebKit security updates

Posted Feb 6, 2016 10:28 UTC (Sat) by flussence (guest, #85566) [Link]

Don't put words in my mouth. I'm saying that my priorities aren't driven by militant, blind idealism. That's why I'm using Chrome, not Lynx-over-RFC822.

Catanzaro: On WebKit security updates

Posted Feb 3, 2016 4:19 UTC (Wed) by butlerm (subscriber, #13312) [Link] (5 responses)

Out of curiosity, how many use cases are there for an embedded web browser accessing arbitrary non-developer controlled content over the Internet? Using embedded WebKit for all sorts of internal uses makes perfect sense, exposing it to the Internet at large, not so much, unless of course developing a web browser is exactly what you have in mind.

Catanzaro: On WebKit security updates

Posted Feb 3, 2016 6:58 UTC (Wed) by JanC_ (guest, #34940) [Link]

Not all dangerous content is accessed directly over the internet, but might still come from a malicious third party; any application that can possibly open documents not provided by the program itself and displays them with WebKitGtk+, possibly after conversion, might have a problem. E.g. e-book readers, help browsers, package managers, …

Catanzaro: On WebKit security updates

Posted Feb 3, 2016 14:54 UTC (Wed) by drag (guest, #31333) [Link] (2 responses)

Email, RSS, chat clients, word processors, and a few other things.

Formatting things in HTML + CSS is a pretty common thing. If you want to design a app but you want to use a standard method for formatting text while allowing for colors, images, styles, and whatnot... that you want to have a good chance of working with other types of similar apps... what standard do you want to be using for this? Postfix? PDF? Rich Text Format? Using HTML/CSS is the obvious choice.

Catanzaro: On WebKit security updates

Posted Feb 3, 2016 20:18 UTC (Wed) by butlerm (subscriber, #13312) [Link] (1 responses)

Okay. However, one would expect the substantial majority of security vulnerabilities in a browser engine to be accessible only using Javascript, and surely running Javascript from untrusted sources is rare outside a web browser itself.

Catanzaro: On WebKit security updates

Posted Feb 4, 2016 7:49 UTC (Thu) by JanC_ (guest, #34940) [Link]

If you look at the actual CVEs linked to from the blog article, you will see that most of them are not directly related to JavaScript; there are a lot of various sorts of buffer overruns, use-after-free, and other memory corruption bugs that can be exploited without any need for JavaScript.

Catanzaro: On WebKit security updates

Posted Feb 4, 2016 20:31 UTC (Thu) by rwmj (subscriber, #5474) [Link]

Presentation tool? TechTalk PSE uses WebKit to render slides, and they can reach out to arbitrary internet resources like Youtube videos (assuming you have an internet connection where you are giving the presentation, of course).

Catanzaro: On WebKit security updates

Posted Feb 3, 2016 7:13 UTC (Wed) by JanC_ (guest, #34940) [Link] (2 responses)

If I understand correctly, a “security fix” would in many cases require a lot of work from the application developers, like porting their application to a new & partially incompatible major toolkit version, and/or porting it to a browser engine component that works completely different from before. Considering that WebKitGtk+ only released its first security advisory one year ago, and only started releasing them regularly on December 28, 2015 (one month ago!), I think it's fairly simple to understand why many application developers haven't seen the benefit and then found the time to finish all that work yet…

So although distros could (and should) certainly do a better job to provide security updates for the benefit of applications that use a supported WebKitGtk+ API, the fact that upstream:
a) seems to break their API every couple of years and then stops support for the old API shortly after
b) only started to make people aware of security issues very very recently (and then released a huge number of them at once)
… is certainly not helping here?

Catanzaro: On WebKit security updates

Posted Feb 3, 2016 15:28 UTC (Wed) by mcatanzaro (subscriber, #93033) [Link] (1 responses)

We only had two API breaks, and one was so small I don't think it affected any application other that Epiphany.

Other than that, you're right on the mark.

Catanzaro: On WebKit security updates

Posted Feb 5, 2016 11:02 UTC (Fri) by JanC_ (guest, #34940) [Link]

The API breaks that were a result of Gtk+ 2 → Gtk+ 3 are also relevant (although mostly not the fault of the WebKit project, of course).