[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Date: Tue, 22 Oct 2013 19:48:40 +0100
From: "Alexander E. Patrakov" <patrakov@...il.com>
To: oss-security@...ts.openwall.com
Subject: CVE request: WebKit-GTK + Puseaudio: unexpectedly high sound volume
Hello.
Some time ago I have reported an issue:
http://seclists.org/oss-sec/2013/q4/35 , but decided not to request
CVE at that time, because I wanted to collect opinions on the topic
"who should fix what". I have collected them from both involved
parties and thus now request a CVE ID for this coordination issue /
case of contradicting requirements. Please let me know if I have
omitted any of the required information.
Let me reproduce the most important part of my initial report.
======
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 [1]. 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
[2].
The reproducer (that just sets the volume at regular intervals using a
timer) 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.
======
Personally, I classify [1] as an annoyance-class bug (but still a bug)
and [2] as a security issue.
Relevant links:
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
Chromium is not vulnerable because it does not attempt to integrate
the javascript volume with the stream volume in PulseAudio. Tested
Windows-based browsers (IE, Firefox, Chrome, Opera) are not vulnerable
for the same reason - the javascript-settable volume does not
correspond to anything in the system mixer. I have not tested Firefox
with GStreamer backend on Linux.
I spoke both to representatives of PulseAudio development team and to
WebKit-GTK developers. The unfortunate conclusion is that no agreement
can be reached upstream on the topic "who should fix what", and no
agreement exists whether this is a bug at all (I was told that I am
the only one who complains, and that I should fix the issue on my own
system by disabing flat volumes, which I did, but I don't consider
this to be a full fix). I should also mention that the current
behaviour is a necessary result of a previous agreement reached at
GUADEC between PulseAudio, GStreamer and WebKit-GTK developers -
that's why the natural resistance to its rediscussion.
As all components are definitely operating as intended according to
the majority of their authors (PulseAudio implements the most
intuitive volume control model according to a published research
paper, WebKit-GTK implements W3C standards and offers the best
possible integration of web applications into that desktop sound
volume model), this bug will, I think, never get fixed upstream.
PulseAudio devs mostly agree that this is a sandboxing issue in
WebKit-GTK. WebKit-GTK developers think that such sandboxing is
possible to do but should not be done because "We want to be coherent
with the rest of GNOME apps, and the volume model they are using"
(even though no other browser attempts that), and suggest to either
fix the volume model or live with it.
My own advice to Linux distributions, which obviously differs from the
upstream opinion of both projects:
1. Disable flat volumes in PulseAudio by default. This would convert
this security issue into a mere "application relative-volume slider
disobeys the user" annoyance-class bug.
2. Persuade upstream developers of WebKit-GTK that full desktop
integration is not a worthy goal for a web browser engine.
One off-topic remark, just to illustrate my opinion: this is not the
first case that I encountered where too much desktop integration is an
issue. The other (non-security) issue is
https://bugzilla.redhat.com/show_bug.cgi?id=755200
--
Alexander E. Patrakov
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.
