Hello. You are receiving this message because Michael Catanzaro (who is, if I understand correctly, a GNOME developer, but not an official developer of Epiphany, the GNOME web browser) advised me to contact the release team what to do about the Epiphany browser vulnerability (initially reported as regular bug #675217, and only long after that was a malicious testcase constructed). The impasse is that nobody thinks that this is a bug in his package, nobody is willing to do anything (because it is someone else's bug or not a bug at all), and thus I concluded that the bug needs to be escalated.
Quoting Michael Catanzaro: > You can also > escalate this to the GNOME release team. They obviously have no control over > our dependencies, but they certainly can refuse to ship the browser so long as > it exhibits this behavior. ...which of course should only be done as a last resort. There must exist other solutions, but my soft skills are not good enough to find them. I have already tried, unsuccessfully, to escalate this to GNOME security team. To understand my viewpoint correctly, please look at this not as a pure _vulnerability_ of Epiphany, but as a _bug_ in WebKit-GTK that exists independently of PulseAudio configuration, but, given that PulseAudio implements flat volumes by default, becomes a vulnerability in that particular default configuration. The _bug_ is: a malicious piece of javascript on the web page can cause an audio file to play at some volume, without the user being able to move the corresponding slider in pavucontrol or gnome-volume-control. I.e. just a "stuck slider" annoyance-class bug, but still a bug. Note that Xabier Rodríguez Calvar disagrees with this being a bug - it is allegedely required by w3c HTML5 standard (except that browsers like Chromium and Firefox comply with the said standard and don't have this bug, due to applying the volume internally before giving audio samples out). The _vulnerability_ is: a malicious piece of javascript on the web page can cause an audio file to play at unexpectedly high volume (up to 100% of the volume that the hardware is capable of, which is way too much e.g. for some headphones), and not let the user move the volume slider corresponding to the web browser, move the "master" volume slider, or mute it. Note: this description of a vulnerability depends on the true fact that there exists audio playback equipment for which 100% soundcard volume is way too much. Of course it does not apply to any equipment that has its own volume control, such as an HDMI-connected home cinema, where 100% soundcard volume is just OK. In this case, only a _bug_ mentioned above remains. A demo prepared by one of my colleagues that illustrates the vulnerability (except the "can't mute" aspect, but that's trivial to add) is available at http://jsfiddle.net/bteam/FbkGD/ - open in Epiphany (without too-sensitive equipment attached to the audio output, and please note that I am not responsible for any damage done by that page), try to reduce the volume and see what happens. A CVE request (still without an answer): http://www.openwall.com/lists/oss-security/2013/10/22/6 The timeline of the problem is as follows: 2012-05-01: I filed https://bugzilla.gnome.org/show_bug.cgi?id=675217 (summary: Epiphany sets sound volume to 100%). This is, essentially, about an ability of a web page to play sounds at 100% hardware volume, disobeying the volume slider, which is IMHO a vulnerability in the web browser. 2013-03-21: Kamil Páral filed https://bugzilla.gnome.org/show_bug.cgi?id=696317 (summary: Reloading a HTML5 video resets sound volume to 100%). Later this bug got marked as a duplicate of my bug. GUADEC 2013: there was some discussion involving at least Lennart Poettering and Xabier Rodríguez Calvar, but not me, about the proper way to initialize volume for pulsesink in WebKit. I.e. basically about bug 696317. Result: they decided not to initialize the volume of the pulsesink in WebKit (and thus avoided bug 696317), but forward all javascript-initiated volume change requests to pulsesink without modification. As I was not at that discussion, nobody raised the argument that it is not a good idea from the security viewpoint. LCE 2013: During the audio miniconf, I raised this issue again. Xabier Rodríguez Calvar was not at that miniconf. There was no consensus. However, with the exception of one person (David Henningsson), the conclusion was that there is no bug in PulseAudio, just a sandboxing issue in WebKit-GTK (if a bug at all). As follows from the above text, I think that the core of this issue is indeed the lack of any sandboxing of sound volume on the path from the web page to the headphones, and that WebKit-GTK is the correct place to add this sandbox. After the audio miniconf, I discussed the issue with Xabier Rodríguez Calvar in person. Some points were made: this behavoiur is perceived as a necessary consequence of following w3c HTML5 standard and having sound volume handling in Epiphany coherent with the rest of the GNOME apps (which "makes sense", except for the end result). And all of that was already discussed, so no point in rediscussing. Moreover, Xabier specifically tested that requests to set any volume go through, and thinks that it would be a bug to do otherwise. Which IMHO makes sense for trusted local HTML5 apps that do need to be consistent with the rest of the desktop, but does not make sense for the browser that is exposed to untrusted javascripts from the Internet (and here is where we disagree). I suggested adding one gobject property to choose between these two behaviours (setting volume on pulsesink for trusted apps vs on the new gstreamer volume element for untrusted content), but Xabier replied that it would incur the unbearable cost of adding one "if" to the codebase and testing it. And he thinks that I am the only person who complains (which is false - we also have David Henningsson and Michael Catanzaro). So, in summary, we have an impasse that you can help to resolve. Since then, I have thought about other undesired consequences of having 1:1 mapping between audio elements on the web page and PulseAudio streams. I have not shared them yet with anyone else, but here they are for your consideration. First, consider a web page that contains hidden 32 audio elements without controls, that play just silence. Result: complete DoS on the whole audio stack, as PulseAudio has a hard-coded limit of 32 simultaneous streams, and no way to guess which tab is responsible. Second, given that WebKit developers are very proud of a possibility of e.g. AC3 audio passthrough from the web page over SPDIF, imagine a web page that contains one such audio element with a silent AC3 file. Result: again, a complete DoS on the audio stack, as no other apps can play anything while this unwanted passthrough stream is active, and, again, no way to guess why. So, maybe the whole idea of offloading as much as possible to pulseaudio (volume handling, in-tab mixing, hw-assisted audio decoding) does not make any sense in the context of the web? Hopefully, this additional information will be useful to you when deciding how to resolve the impasse. -- Alexander E. Patrakov _______________________________________________ [email protected] https://mail.gnome.org/mailman/listinfo/release-team Release-team lurker? Do NOT participate in discussions.
