[pulseaudio-discuss] PulseAudio vulnerable to CVE-2009-1894

[Lennart Poettering]

On Thu, 23.07.09 14:38, Zygo Blaxell (zygo.blaxell at xandros.com) wrote:

> On Wed, Jul 22, 2009 at 07:37:28PM +0200, Lennart Poettering wrote:
> > On Thu, 16.07.09 16:16, Diego E. ???Flameeyes??? Petten?? (flameeyes at gmail.com) wrote:
> > > The fix (pending merge on master branch) is available on my branch:
> > > 
> > > http://gitorious.org/~flameeyes/pulseaudio/flameeyes-pulseaudio
> > > 
> > > http://gitorious.org/~flameeyes/pulseaudio/flameeyes-pulseaudio/commit/84200b423ebfa7e2dad9b1b65f64eac7bf3d2114
> [...]
> > OTOH the whole feature of enforcing immediate binding is a bit
> > snake-oilish. And redundant on prelink-enabled systems. So maybe
> > dropping the entire feature wouldn't be that bad after all...
> 
> Coincidentally, for a while now I've been using a modified build
> of pulseaudio that has the whole ltdl_bind_now feature stripped out
> of it.  Why, you might ask?  Because without the ltdl_bind_now stuff,
> pulse 0.9.15-stable can be built with older versions of libtool and
> libltdl-dev (like the ones in Debian Lenny).
> 
> I'm not sure quite what the bind_now stuff is trying to achieve.
> The stated purpose is simple enough, but as far as I can tell pulse
> isn't doing a bunch of other things that would be needed to avoid
> all unexpected delays in real-time code (e.g. preloading and locking code
> pages in RAM, preallocating stack, and so forth).  It also seems to me
> that most of these delays can be avoided by simply executing a complete
> cycle of the audio processing loop once, and most human observers won't
> notice even the worst case delays in the first loop iteration (and
> the humans who do notice can start the PA daemon in advance and/or play some
> silent preroll samples with the specific sink inputs they intend to
> use).

Sure. Enforcing the bind now logic is a bit snake-oilish. But uh, otoh
it was relatively easy to do.

If you follow the textbook when writing real-time applications
you'll find a substantial number of recommendations what to do and
what not to do in RT apps. Many of these techniques we cannot use in
PA because PA is just one service among many and not the primary
reason your power on your computer. For example, locking PA fully into
memory basically makes a substantial part of your machine's RAM
unavailable to other applications. Given that PA maintains sample
caches and stuff like this PA's memory usage can be not exactly
small. If we'd lock the entire PA process into memory this would hence
result in a reduction of RAM available for everyone else effectively
meaning quite a slow down. Instead we decided to go for a "softer" way
to handle the risk of swapped out memory (MADV_WILLNEED).

So yepp, because PA is part of every user session, and usually just an
auxilary part of it we have to compromise. And decide individually on
every technology in question if it makes sense to adopt it or not. So
memlock() certainly is too expensive, but on the other hand BIND_NOW
is very easy to do and cheap, and that's why we did it.

> So I'm all in favor of dropping the feature.  If the ltdl_bind_now stuff
> goes away, can the libtool dependency be downgraded as well?

Hmm, uh. The changes between 1.5 and 2.2 were quite substantial, not
only in libltdl but also in the autoconf support and stuff. PA
requires quite a few very modern external dependencies anyway, so I
see not much value in support obsolete versions of libtool. I mean,
you now need a very new udev, and a new kernel and a new alsa anyway,
so why should lt be the dependency where we still support really old
versions?

PA needs very new dependencies all over the place, and this won't
change anytime soon. Sorry.

Lennart

-- 
Lennart Poettering                        Red Hat, Inc.
lennart [at] poettering [dot] net
http://0pointer.net/lennart/           GnuPG 0x1A015CC4