[pulseaudio-discuss] Vulnerability in Webkit-GTK and PulseAudio volume handling

Tue Oct 8 12:33:42 CEST 2013

Hello.

Note: this is not a CVE request yet! Before making a formal CVE request, 
I would need to collect "official" information on the topic who needs to 
do what with this bug (although I do have my own opinion, see below). 
For now, I just want to start a discussion by posting this to the 
relevant mailing lists, and also I want to avoid the situation where 
each side blames the other. Please note that I am not an upstream 
developer of any of the mentioned projects. I will attend the audio 
mini-conference at LinuxCon Europe 2013, it is OK to discuss the issue 
there if representatives from both parties intend to come.

The following combination of software has a nasty bug when used 
together, that I personally consider to be a vulnerability:

* PulseAudio (any version, especially when used in flat-volume mode that 
is the default everywhere except Ubuntu).
* Any browser based on Webkit-GTK 2.x (any version with HTML5 
audio/video support based on GStreamer).

The bug is that a malicious piece of javascript on the web page can 
cause an audio file to play at an unexpectedly high volume, not obeying 
the volume that the user has set for the web browser in pavucontrol or 
gnome-volume-control, and effectively not letting the user move the 
volume slider corresponding to the web browser. When flat volumes are in 
effect, the web page can play that audio file at the full volume that 
the sound card is capable of, which can in some cases damage 
loudspeakers (especially tweeters) or the user's hearing.

The reproducer is already public at http://jsfiddle.net/bteam/FbkGD/ and 
can be trivially enhanced to also prevent muting of the audio stream. 
View that in Epiphany or Midori on any Linux distribution except Ubuntu.

My own opinion is that both parties are equally responsible for the 
vulnerability. The salt of the bug is that PulseAudio's security model 
is based on clients not sending malicious requests to change the stream 
volume, while Webkit passes all volume-changing requests (including 
malicious) to GStreamer, because it has no way of telling user-initiated 
volume change requests from automated malicious ones.

Even with non-flat volumes, passing the javascript-initiated volume
changes to pulseaudio means that the user cannot drag the "Epiphany"
volume slider or (with a trivial change to the JavaScript on the page)
mote the Epiphany stream in pavucontrol. So, in my opinion, using a 
pulseaudio stream volume to represent javascript volume (or, for that 
matter, the volume visible to any other runtime that can execute 
untrusted programs/scripts) is always wrong.

However, the fact that flat volumes are enabled by default in upstream 
PulseAudio makes this small annoyance a real vulnerability. Given that 
the "100% hardware volume" type of bug is still present in some 
applications given the vast amount of time the feature exists, I think 
(but understand that it is an extreme position) that flat-volume mode, 
by its mere existence, is a bug that needs to be removed. At the very 
minimum, there is a documentation bug: it is nowhere explained that you 
should never use PulseAudio stream volumes (and for that matter, 
gstreamer sink volumes) for things that are not guaranteed to directly 
correspond to user-draggable volume sliders that no automated script can 
also move.