[FFmpeg-devel] Security issues?

[Baptiste Coudurier]

On 9/24/09 3:27 PM, Michael Niedermayer wrote:
> On Wed, Sep 23, 2009 at 09:33:21PM -0700, Baptiste Coudurier wrote:
>> On 09/23/2009 11:48 AM, Michael Niedermayer wrote:
>>> On Wed, Sep 23, 2009 at 11:11:37AM -0700, Baptiste Coudurier wrote:
>>>> On 09/23/2009 02:33 AM, Michael Niedermayer wrote:
>>>>> On Tue, Sep 22, 2009 at 08:09:08PM +0200, Michael Niedermayer wrote:
>>>>>> Hi
>>>>>>
>>>>>> lars has mailed me the following 2 links
>>>>>> http://www.heise.de/newsticker/Sicherheitsluecken-in-VLC-und-FFmpeg--/meldung/145655
>>>>>> http://secunia.com/advisories/36805/
>>>>>
>>>>> next is for mov:
>>>>>
>>>>> http://src.chromium.org/viewvc/chrome/trunk/deps/third_party/ffmpeg/patches/to_upstream/35_mov_bad_timings.patch?revision=25101&view=markup
>>>>>
>>>>> this probably isnt security relevant but still should be fixed
>>>>> issue is that 32bits are read into an (signed) int and thus one can
>>>>> end with a negative time_scale, chromes patch looks wrong
>>>>> changing time_scale to unsigned seems the solution at first but its
>>>>> assigned to sample_rate and time_base which themselfs are signed ...
>>>>
>>>> Yes patch is wrong, specs says time_scale is unsigned. Field must be
>>>> changed to unsigned.
>>>
>>>> sample_rate and time_base should also be unsigned
>>>> IMHO, but this might have side effects ...
>>>
>>> time_base is AVRational which are 2 signed ints, its hard to change that
>>> about sample_rate, i agree in principle but a value>0x7FFFFFFF is a bug
>>> anyway
>>>
>>
>> Here a proposed patch, not sure if it's better than checking for<  0
>> though.
>
> not sure either what is best but iam definitly fine with the patch or a
> <0 check

Fixed the 0 case to avoid fpe.

-- 
Baptiste COUDURIER
Key fingerprint                 8D77134D20CC9220201FC5DB0AC9325C5C1ABAAA
FFmpeg maintainer                                  http://www.ffmpeg.org