[webkit-gtk] Vulnerability in Webkit-GTK and PulseAudio volume handling
gmane at colin.guthr.ie
Thu Oct 10 12:50:17 PDT 2013
'Twas brillig, and Alexander E. Patrakov at 08/10/13 11:33 did gyre and
> 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).
> 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.
> changes to pulseaudio means that the user cannot drag the "Epiphany"
> mote the Epiphany stream in pavucontrol. So, in my opinion, using a
> 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.
> See also:
It's certainly an interesting issue and your code highlights the problem
I'm not sure I consider it a technical vulnerability tho' (just my
personal opinion) but I do appreciate the damage to both h/w and hearing
that could result and thus I won't argue about classifying it as such.
What would be more interesting to me would be how the same code works on
Windows 7 which I believe also implements a flat volume scheme (not sure
about Win 8) and how it handles stream volumes in this context
Look forward to seeing you in a couple weeks at LinuxCon!
Tribalogic Limited http://www.tribalogic.net/
Mageia Contributor http://www.mageia.org/
PulseAudio Hacker http://www.pulseaudio.org/
Trac Hacker http://trac.edgewall.org/
More information about the webkit-gtk