Jeremy Morton <ffm...@game-point.net> added the comment: > ffmpeg is no firewall
I don't think this is really firewall functionality. > also your patch would require changes to every single user application > to have any effect. No it wouldn't, existing apps would be unaffected, because as you say below this would be an API change. Whatsmore, it could be implemented as optional by enabling it using a build switch. > If you want an extension of libavformats API this is possible but only > after someone proofed the need for such change, that is someone MUST > read the RFCs about RTP&RTSP&SDP and then explain exactly > > * why the *SRC & SEQ numbers are not sufficient. If i'm opening an SDP file or just directly opening an rtp:// URL (I'm opening an SDP file) in order to wait for an RTP stream to be sent to me, there is nowhere I can specify those numbers. Even if I could, there is no formal mechanism for my program to get those numbers from the sender, so I wouldn't know which one was the one to throw away and which to keep. Also, lazy firmware implementers can just set the SSRC to 0 (and do, I've seen it), so multiple streams could have the SSRC 0, becoming indistinguishable. > * what exact attack scenario is possible due to this Multiple streams being sent in to a transcoding server that receives RTP streams and outputs them to eg. a Flash client using RTMP. There's only 65535 port numbers to choose from, malicious attackers can likely send valid camera data to port(s) being used for receiving streams. > * how this can be fixed I've posted a sample diff in this issue which fixes this (proof-of-concept), by allowing the calling code to register a callback function which can check the source network address to make sure it's the address (ie. the address of the sender; a network camera in this case) it expected to receive the packet from. It can return zero or nonzero to reject or accept the packet. > No bugfix without reproduceable bug! Open an SDP file describing an RTP stream on localhost with a common codec (say MP4V-ES) on a certain port, then send 2 streams to that port with an SSRC of 0. The decoding will screw up. But bear in mind that even with valid SSRCs, multiple problems I listed above still apply. _____________________________________________________ FFmpeg issue tracker <iss...@roundup.ffmpeg.org> <https://roundup.ffmpeg.org/roundup/ffmpeg/issue1688> _____________________________________________________
