7 ms·

On WebKit Security Updates

135 points by raimue 11y ago

ianlevesque 11y ago
"WebKit does have a Linux sandbox, but it’s not any good, so it’s (rightly) disabled by default." I'd love to know more about why, that seems mad in 2016.
- creshal 11y ago
  Disabling a broken feature, or not fixing it? The latter is easily explained: Webkit (especially on Linux) is woefully short of manpower now that Google et. al. have pulled out of it. I'll call myself lucky if WebkitGTK doesn't crash on any of the Alexa top 100 any more.
  - josteink 11y ago
    Just in time for Emacs, XWidget support and Webkit embedded in Emacs then. And here I thought we'd finally get a quality browser-engine for our OS. Seems we'll have to wait some more :)
    - creshal 11y ago
      Chromium Embedded Framework (used by e.g. Qt, Android, and browsers like Vivaldi) is okay, and Servo (Mozilla's new rendering engine in Rust) is aiming to be API compatible to it. Seems it's where we're headed for now.
- madeofpalk 11y ago
  My (very brief and shallow) understanding of one thing that may contribute to the problem was a disagreement of where the sandboxing took place. Chrome devs believed it should happen in the engine (Webkit), whereas Safari devs believed it should happen in the end browser (Safari). So IIRC, Webkit doesn't really have first class support for sandboxing as Apple has 'their own' sandboxing built into Safari. Of course, I'm likely to be completely wrong. I remember this being brought up back when the Webkit/Blink fork happen, and in my recent brief search I haven't been able to find any sources again.
  - pcwalton 11y ago
    > Chrome devs believed it should happen in the engine (Webkit), whereas Safari devs believed it should happen in the end browser (Safari). No, that's actually pretty much backwards. Chromium believed the sandboxing should happen at the browser level, with WebKit communicating to the trusted chrome process via the "WebKit port" named "chromium", which is basically just a set of IPC hooks that expect to be talking to Chromium on the other side. WebKit2 was designed to bring both the trusted and untrusted parts of the project under the WebKit umbrella, and as a result it had tighter integration. The Blink fork has made this less of an issue, since now chrome and content code are under single repositories (Chromium and WebKit) in both projects. However, you still see evidence of this all over the place. For example, Blink's content code largely follows WebKit coding style as opposed to the chrome code which follows Google's corporate style, while WebKit's coding style is unified for both chrome and content.
ufo 11y ago
Its kind of sad that text and image documents today are so complicated that security vulnerabilities in software that reads them are considered inevitable.
- SquareWheel 11y ago
  Web browsers are one of the most complicated pieces of software on your computer. Many webpages are now webapps, and more comparable to programs than text documents. This is not necessarily a bad thing as it allows much more interaction between user and server. But complexity often means more bugs, and thus more vulnerabilities.
- pcwalton 11y ago
  Complexity is inevitable. The problem (well, one of the largest problems) is that we have collectively failed to come up with effective mitigations for these basic memory safety issues (other than sandboxing). At best we don't invest enough in effective solutions; at worst we incorrectly convince ourselves that "good programmers" never create exploitable security vulnerabilities. Just look at the list: http://webkitgtk.org/security/WSA-2015-0002.html http://webkitgtk.org/security/WSA-2015-0002.html "Memory corruption and application crash" appears more times than I can count.
  - sebcat 11y ago
    Sandboxing is great. Isolate certain functionality in a separate process, sandbox it with OS-provided solutions like seccomp-bpf or capsicum, make it terminate on a violation, design its API to be idempotent so you can just restart the process on failure. Have rlimits on process memory usage. There are technical solutions and development processes to write better, more secure software. The problem is of course that software has to be designed for this, it's not something that can easily be slapped on as an afterthought. It demands more of the design, and that's not easy to motivate in most organisations. Forcing the developer to take security into consideration would be better, but the root of the problem is that most organisations don't consider security that important, even if they say they do.
kangaroo 11y ago
Why is this so bad? Because the WebKit security group doesn't let new members in. Its a self perpetuating cycle.
sambe 11y ago
Interesting. I have one major disagreement. This: "This seems to me like a good reason for application maintainers to carefully test the updates" Doesn't seem remotely feasible. Every security release should be manually QA'd by the distribution? If they are already worried enough not to take such updates, I doubt they have the manpower to cover everything not covered by integration tests (a lot?).
- greggman 11y ago
  Well, there are 100s of thousands of tests checked into various repos. WebKit has > 45k tests and there are open test suites for many web apis. Of course it's work to get some testing infrastructure setup but once setup it's mostly automated? I supposed not, it just adds something else that needs to be maintained :P
  - makomk 11y ago
    One would hope that whoever committed the patches already ran those tests, so the bugs that get through will mostly be ones that the tests couldn't catch - for example, issues with applications that integrate WebKitGTK+ not functioning properly with the new version. Incidentally, GTK+ as a whole has a terrible record when it comes to backwards-compatibility these days. And as the post makes clear, the security upgrades doesn't even help that much because the original WebKitGTK+ API isn't receiving them anymore and moving to the new API requires massive changes that distros certainly can't ship in an update to a stable release. Apparently they gave applications "a full year to upgrade", which is shorter than the lifespan of distro releases and not realistic given that it requires upgrading to GTK+ 3 and more major changes on top of that. Just the GTK+ 3 switch alone is a multi-year project for complex software, and not helped by the fact they keep breaking their API in new versions. Case in point: https://bugzilla.gnome.org/show_bug.cgi?id=757503 https://bugzilla.gnome.org/show_bug.cgi?id=757503
awalGarg 11y ago
> Web engines are full of security vulnerabilities, like buffer overflows, null pointer dereferences, and use-after-frees. Off-topic to the issue at hand, but I am curious: would Servo[1], the browser engine written in Rust be having lesser (chances of) issues like this? I have written very little Rust, but it seems that the above issues are extremely unlikely to occur with Rust. [1]: https://servo.org/ https://servo.org/
- neikos 11y ago
  Unless they mis-use `unsafe` the chances are very low and would be in the compiler rather than the source code. So yes, those errors should not appear. Others are still possible and might be just as bad.
- notalaser 11y ago
  Never underestimate what misguided cleverness can do. Heartbleed, the most famous of these issues in the last few years, would have not occurred on systems like OpenBSD, were it not for its developers' quest for optimization in their malloc wrapper. I've seen buffer overflows in Java, too. It's immune to writing past the end of the arrays, but it's not immune to, say, smart programmers using one large array to hold multiple buffers that they manually manage, because who knows when the GC kicks in and wrecks havoc. Python may be immune to use-after-frees, but the OpenGL bindings that it calls through the FFI aren't. To err is human, and languages like Rust don't make it less likely to err, they just give you new opportunities to do it. Moving to a safe language like Rust would help, absolutely, but to a far lesser degree than people hope. It would close far fewer cans of worms than the hive mind hopes, and it's so new no one really knows how big its own can of worms is.
  - orf 11y ago
    > and languages like Rust don't make it less likely to err It doesn't make the person less likely to err overall, but it makes it less likely that those errors get compiled and released.
    - notalaser 11y ago
TazeTSchnitzel 11y ago
Devices with old WebKit versions are fun. A lot of hacks used for homebrew on the Nintendo 3DS have relied on unpatched WebKit bugs. Vendors never update their WebKit versions, and Nintendo is no exception.
ryan-c 11y ago
Many of the obscure WebKit browsers do not validate certificates on subresources, which allows MitM attackers to replace third party scripts with malicious ones. Some of them do this without even any UI indication that there is a problem. I have a test page here: https://rya.nc/https-script.html https://rya.nc/https-script.html

135 points by raimue 11y ago

"WebKit does have a Linux sandbox, but it’s not any good, so it’s (rightly) disabled by default." I'd love to know more about why, that seems mad in 2016.

creshal 11y ago
Disabling a broken feature, or not fixing it? The latter is easily explained: Webkit (especially on Linux) is woefully short of manpower now that Google et. al. have pulled out of it. I'll call myself lucky if WebkitGTK doesn't crash on any of the Alexa top 100 any more.
- josteink 11y ago
  Just in time for Emacs, XWidget support and Webkit embedded in Emacs then. And here I thought we'd finally get a quality browser-engine for our OS. Seems we'll have to wait some more :)
  - creshal 11y ago
    Chromium Embedded Framework (used by e.g. Qt, Android, and browsers like Vivaldi) is okay, and Servo (Mozilla's new rendering engine in Rust) is aiming to be API compatible to it. Seems it's where we're headed for now.
madeofpalk 11y ago
My (very brief and shallow) understanding of one thing that may contribute to the problem was a disagreement of where the sandboxing took place. Chrome devs believed it should happen in the engine (Webkit), whereas Safari devs believed it should happen in the end browser (Safari). So IIRC, Webkit doesn't really have first class support for sandboxing as Apple has 'their own' sandboxing built into Safari. Of course, I'm likely to be completely wrong. I remember this being brought up back when the Webkit/Blink fork happen, and in my recent brief search I haven't been able to find any sources again.
- pcwalton 11y ago
  > Chrome devs believed it should happen in the engine (Webkit), whereas Safari devs believed it should happen in the end browser (Safari). No, that's actually pretty much backwards. Chromium believed the sandboxing should happen at the browser level, with WebKit communicating to the trusted chrome process via the "WebKit port" named "chromium", which is basically just a set of IPC hooks that expect to be talking to Chromium on the other side. WebKit2 was designed to bring both the trusted and untrusted parts of the project under the WebKit umbrella, and as a result it had tighter integration. The Blink fork has made this less of an issue, since now chrome and content code are under single repositories (Chromium and WebKit) in both projects. However, you still see evidence of this all over the place. For example, Blink's content code largely follows WebKit coding style as opposed to the chrome code which follows Google's corporate style, while WebKit's coding style is unified for both chrome and content.

ufo 11y ago

Its kind of sad that text and image documents today are so complicated that security vulnerabilities in software that reads them are considered inevitable.

SquareWheel 11y ago
Web browsers are one of the most complicated pieces of software on your computer. Many webpages are now webapps, and more comparable to programs than text documents. This is not necessarily a bad thing as it allows much more interaction between user and server. But complexity often means more bugs, and thus more vulnerabilities.
pcwalton 11y ago
Complexity is inevitable. The problem (well, one of the largest problems) is that we have collectively failed to come up with effective mitigations for these basic memory safety issues (other than sandboxing). At best we don't invest enough in effective solutions; at worst we incorrectly convince ourselves that "good programmers" never create exploitable security vulnerabilities. Just look at the list: http://webkitgtk.org/security/WSA-2015-0002.html http://webkitgtk.org/security/WSA-2015-0002.html "Memory corruption and application crash" appears more times than I can count.
- sebcat 11y ago
  Sandboxing is great. Isolate certain functionality in a separate process, sandbox it with OS-provided solutions like seccomp-bpf or capsicum, make it terminate on a violation, design its API to be idempotent so you can just restart the process on failure. Have rlimits on process memory usage. There are technical solutions and development processes to write better, more secure software. The problem is of course that software has to be designed for this, it's not something that can easily be slapped on as an afterthought. It demands more of the design, and that's not easy to motivate in most organisations. Forcing the developer to take security into consideration would be better, but the root of the problem is that most organisations don't consider security that important, even if they say they do.

kangaroo 11y ago

Why is this so bad? Because the WebKit security group doesn't let new members in. Its a self perpetuating cycle.

sambe 11y ago

Interesting. I have one major disagreement. This: "This seems to me like a good reason for application maintainers to carefully test the updates" Doesn't seem remotely feasible. Every security release should be manually QA'd by the distribution? If they are already worried enough not to take such updates, I doubt they have the manpower to cover everything not covered by integration tests (a lot?).

greggman 11y ago
Well, there are 100s of thousands of tests checked into various repos. WebKit has > 45k tests and there are open test suites for many web apis. Of course it's work to get some testing infrastructure setup but once setup it's mostly automated? I supposed not, it just adds something else that needs to be maintained :P
- makomk 11y ago
  One would hope that whoever committed the patches already ran those tests, so the bugs that get through will mostly be ones that the tests couldn't catch - for example, issues with applications that integrate WebKitGTK+ not functioning properly with the new version. Incidentally, GTK+ as a whole has a terrible record when it comes to backwards-compatibility these days. And as the post makes clear, the security upgrades doesn't even help that much because the original WebKitGTK+ API isn't receiving them anymore and moving to the new API requires massive changes that distros certainly can't ship in an update to a stable release. Apparently they gave applications "a full year to upgrade", which is shorter than the lifespan of distro releases and not realistic given that it requires upgrading to GTK+ 3 and more major changes on top of that. Just the GTK+ 3 switch alone is a multi-year project for complex software, and not helped by the fact they keep breaking their API in new versions. Case in point: https://bugzilla.gnome.org/show_bug.cgi?id=757503 https://bugzilla.gnome.org/show_bug.cgi?id=757503

awalGarg 11y ago

> Web engines are full of security vulnerabilities, like buffer overflows, null pointer dereferences, and use-after-frees. Off-topic to the issue at hand, but I am curious: would Servo[1], the browser engine written in Rust be having lesser (chances of) issues like this? I have written very little Rust, but it seems that the above issues are extremely unlikely to occur with Rust. [1]: https://servo.org/ https://servo.org/

neikos 11y ago
Unless they mis-use `unsafe` the chances are very low and would be in the compiler rather than the source code. So yes, those errors should not appear. Others are still possible and might be just as bad.
notalaser 11y ago
Never underestimate what misguided cleverness can do. Heartbleed, the most famous of these issues in the last few years, would have not occurred on systems like OpenBSD, were it not for its developers' quest for optimization in their malloc wrapper. I've seen buffer overflows in Java, too. It's immune to writing past the end of the arrays, but it's not immune to, say, smart programmers using one large array to hold multiple buffers that they manually manage, because who knows when the GC kicks in and wrecks havoc. Python may be immune to use-after-frees, but the OpenGL bindings that it calls through the FFI aren't. To err is human, and languages like Rust don't make it less likely to err, they just give you new opportunities to do it. Moving to a safe language like Rust would help, absolutely, but to a far lesser degree than people hope. It would close far fewer cans of worms than the hive mind hopes, and it's so new no one really knows how big its own can of worms is.
- orf 11y ago
  > and languages like Rust don't make it less likely to err It doesn't make the person less likely to err overall, but it makes it less likely that those errors get compiled and released.
  - notalaser 11y ago

TazeTSchnitzel 11y ago

Devices with old WebKit versions are fun. A lot of hacks used for homebrew on the Nintendo 3DS have relied on unpatched WebKit bugs. Vendors never update their WebKit versions, and Nintendo is no exception.

ryan-c 11y ago

Many of the obscure WebKit browsers do not validate certificates on subresources, which allows MitM attackers to replace third party scripts with malicious ones. Some of them do this without even any UI indication that there is a problem. I have a test page here: https://rya.nc/https-script.html https://rya.nc/https-script.html