[FFmpeg-trac] #1865(avformat:new): sctp.c: abort() call can be hit by bad user input

FFmpeg trac at avcodec.org
Mon Oct 29 16:29:47 CET 2012


#1865: sctp.c: abort() call can be hit by bad user input
-----------------------------------+--------------------------------------
             Reporter:  divVerent  |                     Type:  defect
               Status:  new        |                 Priority:  normal
            Component:  avformat   |                  Version:  git-master
             Keywords:             |               Blocked By:
             Blocking:             |  Reproduced by developer:  0
Analyzed by developer:  0          |
-----------------------------------+--------------------------------------
 Summary of the bug:
 Because ffmpeg is a library, a mere bad URL passed to avio/ffurl code
 really shouldn't be able to cause a hard abort. However, exactly this is
 the case...

 How to reproduce:
 First set up a sctp listener:
 {{{
 % withsctp nc -vlp 127.0.0.1 1234
 }}}
 On another shell:
 {{{
 % catchsegv ./ffmpeg -f lavfi -i "life [out0]" -f nut
 "sctp://127.0.0.1:1234?max_streams=1"
 ffmpeg version N-46130-g67420b3 Copyright (c) 2000-2012 the FFmpeg
 developers
   built on Oct 29 2012 16:09:38 with gcc 4.7.2 (GCC)
   configuration:
   libavutil      52.  1.100 / 52.  1.100
   libavcodec     54. 69.100 / 54. 69.100
   libavformat    54. 35.100 / 54. 35.100
   libavdevice    54.  3.100 / 54.  3.100
   libavfilter     3. 20.106 /  3. 20.106
   libswscale      2.  1.101 /  2.  1.101
   libswresample   0. 16.100 /  0. 16.100
 [lavfi @ 0x23cf260] Estimating duration from bitrate, this may be
 inaccurate
 Input #0, lavfi, from 'life [out0]':
   Duration: N/A, start: 0.000000, bitrate: N/A
     Stream #0:0: Video: rawvideo (B0W1 / 0x31573042), monob, 320x240 [SAR
 1:1 DAR 4:3], 25 tbr, 25 tbn, 25 tbc
 Aborted
 }}}

 Why does it crash? Because the option max_streams in sctp.c causes packets
 to be required to start with the stream index in the first 16 bits of each
 packet to send. And e.g. the nut muxer does not ensure this.

 The danger is that any generic code using avio and letting the URL come
 from user - or worse - untrusted sources (possibly after verifying
 protocol and host name) can crash this way.

 This error condition probably should rather cause a log message with error
 return to packet sending, instead... or the max_streams option should
 rather be implemented in a way so it's not part of the URL, but rather a
 parameter the calling code has to set using a function.

-- 
Ticket URL: <https://ffmpeg.org/trac/ffmpeg/ticket/1865>
FFmpeg <http://ffmpeg.org>
FFmpeg issue tracker


More information about the FFmpeg-trac mailing list