Impasse with GNOME bug 675217

["Alexander E. Patrakov" <patrakov gmail com>]

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