[Bug 793441] rtsp-stream: client transport is not updated for multicast clients

[GStreamer (GNOME Bugzilla)]

https://bugzilla.gnome.org/show_bug.cgi?id=793441

Sebastian Dröge (slomo) <slomo at coaxion.net> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
 Attachment #369332|none                        |needs-work
             status|                            |

--- Comment #46 from Sebastian Dröge (slomo) <slomo at coaxion.net> ---
Comment on attachment 369332
  --> https://bugzilla.gnome.org/attachment.cgi?id=369332
Removed test_client_multicast_invalid_transport_specific

It seems like here something is also missing, let's see the spec:

   destination:
          The address to which a stream will be sent. The client may
          specify the multicast address with the destination parameter.
          To avoid becoming the unwitting perpetrator of a remote-
          controlled denial-of-service attack, a server SHOULD
          authenticate the client and SHOULD log such attempts before
          allowing the client to direct a media stream to an address not
          chosen by the server. This is particularly important if RTSP
          commands are issued via UDP, but implementations cannot rely
          on TCP as reliable means of client identification by itself. A
          server SHOULD not allow a client to direct media streams to an
          address that differs from the address commands are coming
          from.

And even more strict with RTSP 2.0:

         perpetrator of a remote-controlled DoS attack, a server MUST
         perform security checks (see Section 21.2.1) and SHOULD log


So we should not just blindly use addresses provided by the client if they
differ from the client's own IP, but need to do some sanity checks. Section
21.2.1 of RTSP 2.0 has some useful guidance for that.

I think the old behaviour of checking the address pool was a poor-man's
solution for that. Only the destinations that are in the pool were allowed to
be selected by the client, not arbitrary ones.

Maybe we need some new API in the server to allow/disallow specific
destinations. A new signal/vfunc. But just allowing everything unconditionally
seems potentially dangerous and wrong for RTSP 2.0 at least.

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the bug.