Moritz Muehlenhoff wrote:
Did you contact upstream, are fixes available for these?
There are bug tracker items available for the two remaining issues [1] [2], but there has been no movement so far.
I've looked into it and the security aspect is fairly easy to fix by just adding an additional sanity check that allows only positive numbers of channels (rule out 0 to avoid CVE-2014-9638 and negative values to avoid CVE-2014-9639).
For the case CVE-2014-9638, I even consider this the proper and complete fix.
In CVE-2014-9639, however, the deeper reason for the appearance of a negative number of channels is an overflow because of several unsuitable data types used in the reading of the wav headers. The proper fix would be to change those data types - which has to be done with great care, in order to avoid shifting the overflow from its current place to a place that might be even less guarded. I haven't gotten around to reviewing the code and fixing this.
But maybe for now we can just stick with the sanity check? It fixes the security aspect and doesn't break any case that wasn't broken already - it however doesn't fix the problem that oggenc refuses to process some theoretically valid (although very uncommon, if existent at all) WAV files with very extreme parameters.
Cheers, Martin [1] https://trac.xiph.org/ticket/2137 [2] https://trac.xiph.org/ticket/2136 -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected]
