[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Thu, 10 Oct 2013 20:50:17 +0100
From: Colin Guthrie <gmane@...in.guthr.ie>
To: oss-security@...ts.openwall.com
Cc: pulseaudio-discuss@...ts.freedesktop.org,webkit-gtk@...ts.webkit.org
Subject: Re: Vulnerability in Webkit-GTK and PulseAudio volume handling
Hi Alexander,
'Twas brillig, and Alexander E. Patrakov at 08/10/13 11:33 did gyre and
gimble:
> 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.
>
> See also:
>
> https://bugs.webkit.org/show_bug.cgi?id=118974
> https://bugzilla.gnome.org/show_bug.cgi?id=675217
> https://bugs.freedesktop.org/show_bug.cgi?id=46466
> https://bugzilla.gnome.org/show_bug.cgi?id=680779
It's certainly an interesting issue and your code highlights the problem
quite well.
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
(background:
http://www.patrickbaudisch.com/publications/2004-Baudisch-CHI04-FlatVolumeControl.pdf)
Look forward to seeing you in a couple weeks at LinuxCon!
Col
--
Colin Guthrie
gmane(at)colin.guthr.ie
http://colin.guthr.ie/
Day Job:
Tribalogic Limited http://www.tribalogic.net/
Open Source:
Mageia Contributor http://www.mageia.org/
PulseAudio Hacker http://www.pulseaudio.org/
Trac Hacker http://trac.edgewall.org/
Powered by blists - more mailing lists
Please check out the
Open Source Software Security Wiki, which is counterpart to this
mailing list.
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
