Uploaded image for project: 'Qt'
  1. Qt
  2. QTBUG-34896

Qt-Webkit based browsers allow web pages to play sounds at 100% hw volume with no way to reduce



    • Type: Bug
    • Status: Reported
    • Priority: P2: Important
    • Resolution: Unresolved
    • Affects Version/s: 4.8.5
    • Fix Version/s: None
    • Component/s: WebKit
    • Labels:
    • Environment:
      The issue is reproducible in Rekonq or Qupzilla under linux with the default configuration, except Ubuntu.


      The bug applies to any browser that uses Qt-WebKit under Linux with PulseAudio. 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 kmix or whatever other pulseaudio-based mixer application. I.e. just a "stuck slider" annoyance-class bug, but still a bug that, when fixed, will eliminate the vulnerability below.

      The vulnerability below is a logical consequence of the bug above. It applies if PulseAudio is in the flat-volume mode (which is true by default, except on Ubuntu) and if something too-sensitive (e.g. headphones) is connected to the sound card output. 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.

      Demo: http://jsfiddle.net/bteam/FbkGD/

      This malicious piece of javascript just sets the volume to 99% or 100% repeatedly using a timer. The example script does not illustrate the "can't mute" part of the bug, but every bad guy with some javascript knowledge can add the "repeated unmuting" part himself.

      Reproducible: Always

      Steps to Reproduce:
      0. Ensure that flat volumes are enabled in /etc/pulse/daemon.conf
      1. Start Konqueror
      2. Go to http://jsfiddle.net/bteam/FbkGD/ (without anything sensitive connected, otherwise I am not responsible for any damage).
      3. Notice the volume in kmix. Try to reduce it.

      Actual Results:
      The volume is 100%, and attempts to reduce it fail. In the worst case, fried speakers and/or very angry neighbours.

      Expected Results:
      The volume should stay what it was before, and should be changeable using kmix. There should be no slider in kmix that disobeys the user!

      The same bug in GNOME's browser is at https://bugzilla.gnome.org/show_bug.cgi?id=675217

      The root cause of the bug is that Qt-WebKit directly connects the javascript-settable volume to pulseaudio stream volume, thus effectively disabling the slider if javascript does something bad. Instead, as all Windows-based browsers do, Qt-WebKit should attenuate the audio samples before sending them to the system, so that the javascript-settable volume applies as an extra factor on top of the volume set by the user in kmix, not instead of it. A way to achieve this is to use a gstreamer volume element, and apply javascript-settable volume to it, not to the final pulsesink element.

      Note that there are web apps in the wild that assume that setting their volume to 100% is safe, because they expect the relative-to-system-mixer volume model. E.g. http://www.fungamescool.com/FunWithDynamite/fun-with-dynamite.html

      It is a documented feature of PulseAudio that, in flat-volume mode, it treats stream volumes relatively to the hardware maximum volume. On LinuxCon Europe 2013, during the audio miniconf, this has been discussed in the GNOME context and decided that it is not a bug in PulseAudio, i.e. that it is a responsibility of a browser engine to sandbox javascript-initiated volume changes.


          Issue Links

          For Gerrit Dashboard: QTBUG-34896
          # Subject Branch Project Status CR V



              annulen Konstantin Tokarev
              patrakov@gmail.com Alexander E. Patrakov
              2 Vote for this issue
              6 Start watching this issue



                  Gerrit Reviews

                  There are no open Gerrit changes