oss-security - Re: [pulseaudio-discuss] Vulnerability in Webkit-GTK and PulseAudio volume handling

Follow @Openwall on Twitter for new release announcements and other news

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <1381481490.4814.13.camel@localhost.localdomain>
Date: Fri, 11 Oct 2013 10:51:30 +0200
From: Xabier Rodríguez Calvar <calvaris@...il.com>
To: General PulseAudio Discussion <pulseaudio-discuss@...ts.freedesktop.org>
Cc: oss-security@...ts.openwall.com, webkit-gtk@...ts.webkit.org
Subject: Re: [pulseaudio-discuss] Vulnerability in Webkit-GTK and PulseAudio
 volume handling

O Xov, 10-10-2013 ás 20:50 +0100, Colin Guthrie escribiu:
> 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)

For Colin to know, before touching anything in WebKitGtk+ the behavior
was that the volume was ramping up to 100% with every website regardless
their volume control.

I met Slomo and Lennart at GUADEC and we thought that the best was
letting the sink, pulsesink in this case, set the volume and we would
just get that for the slider, regardless the volume model applied. This
was supposed to be a good compromise for the different situations (using
PA with or without flat volumes, using another sink) as volume wouldn't
ramp up to 100% always.

There are some other restrictions we have to observe, though:

     1. We want to be agnostic of the GStreamer sink used and of course,
        to the volume model used by pulse, because we don't know it.
     2. We want to allow audio passthrough when possible.
     3. We want to be coherent with the rest of GNOME apps, and the
        volume model they are using.
     4. We have to comply with the HTML5 W3C standard that says that
        volume will be 100% by default, though user agents can decide to
        restore former volume (perfect if we let pulse decide it).

We would easily add a GStreamer volume element and solve what Alexander
says, buy we would be breaking 2 and 3 rules and to fulfill 3 and 4, I
actually tested that with the proposed fix, the volume could still ramp
up to 100% because in our opinion, it is up to the web developer to
sanitize their volume management or up to the user to change the volume
model.

Best regards.

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.