[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#734746: Fwd: Flite CVE question you asked.



In response to Paul's request for someone with more familiarity with flite code base regarding
whether it is possible to access the patched function from a11y programs.

I have some knowledge of flite as I keep my own fork which mixes flite and festival etc.
(It is not a replacement for flite or festival).

I have checked the patch which involves play_wave_from socket(). This function can also be called 
indirectly via auserver_process_client() and auserver() functions.

Within flite, it was intended to be called via a /testsuite binary which Debian does not build.

The main flite binary packages does not call any of these functions. 

Paul has kindly provided a reverse depends of libflite1 and its dev package.

paul@wollumbin ~ $ reverse-depends libflite1
Reverse-Depends
===============
* asterisk-flite
* brltty-flite
* eflite
* flite
* flite1-dev
* gnustep-gui-runtime
* gstreamer0.10-plugins-bad
* gstreamer1.0-plugins-bad
* pd-flite
* speech-dispatcher
paul@wollumbin ~ $ reverse-depends -b flite1-dev
Reverse-Build-Depends
=====================
* basic256
* brltty
* eflite
* gnustep-gui
* pd-flite
* speech-dispatcher

I have undertood and checked the source code of asterisk-flite, brltty-flite, eflite, gnustep-gui, both
gstreamer plugins (0.1 and 1.0+) , pd-flite, speech-dispatcher and basic256 in relation to interfacing
with flite libraries.
In none of these cases do these codes call (whether directly or indirectly) the insecure functions.

Essentially you would have to deliberately link your own code to these functions in libflite1 to get
access to the insecure code.

I hope this assists you in your backporting security decision.

Please ask if you have any other questions.

best regards,
Peter


Reply to: