After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 668320 - rtpmanager: RTCP receiver reports reveal full user name
rtpmanager: RTCP receiver reports reveal full user name
Status: RESOLVED FIXED
Product: GStreamer
Classification: Platform
Component: gst-plugins-good
git master
Other Linux
: High blocker
: 0.10.31
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Blocks:
 
 
Reported: 2012-01-20 09:22 UTC by lr
Modified: 2012-01-23 17:34 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description lr 2012-01-20 09:22:51 UTC
When watching RTSP video streams with gstreamer, the user name (linux username as well as the real name!) is included in the RTCP receiver reports that are sent back to the streaming server in the CNAME (user and domain) and NAME (full user name) of the SDES per default.

This doesn't seem like a very safe default setting and should be at most optional. The SSRC is already unique, and there are plenty other options to distinguish the user in question. (e.g. use the numeric UID and no real name).
Comment 1 lr 2012-01-20 09:28:34 UTC
Here is an example of such an RTCP packet (user@domain and User Name contained my real user name, host and real name!):

No.     Time        Source                Destination           Protocol Length Info
   5913 322.121637  192.168.2.136         74.125.218.214        RTCP     126    Receiver Report   Source description   

Frame 5913: 126 bytes on wire (1008 bits), 126 bytes captured (1008 bits)
Ethernet II, Src: ***_**:**:** (OMITTED), Dst: **** (OMITTED)
Internet Protocol Version 4, Src: 192.168.2.136 (192.168.2.136), Dst: 74.125.218.214 (74.125.218.214)
User Datagram Protocol, Src Port: 37423 (37423), Dst Port: 10581 (10581)
    Source port: 37423 (37423)
    Destination port: 10581 (10581)
    Length: 92
    Checksum: 0xfc99 [validation disabled]
Real-time Transport Control Protocol (Receiver Report)
    10.. .... = Version: RFC 1889 Version (2)
    ..0. .... = Padding: False
    ...0 0001 = Reception report count: 1
    Packet type: Receiver Report (201)
    Length: 7 (32 bytes)
    Sender SSRC: 0xb6d31fb5 (3067289525)
    Source 1
        Identifier: 0x34b7df92 (884465554)
        SSRC contents
        Extended highest sequence number received: 46847
        Interarrival jitter: 1171
        Last SR timestamp: 327289053 (0x138208dd)
        Delay since last SR timestamp: 73582 (1122 milliseconds)
Real-time Transport Control Protocol (Source description)
    10.. .... = Version: RFC 1889 Version (2)
    ..0. .... = Padding: False
    ...0 0001 = Source count: 1
    Packet type: Source description (202)
    Length: 12 (52 bytes)
    Chunk 1, SSRC/CSRC 0xB6D31FB5
        Identifier: 0xb6d31fb5 (3067289525)
        SDES items
            Type: CNAME (user and domain) (1)
            Length: 15
            Text: user@host <- USER NAME AND HOST IN PLAINTEXT
            Type: NAME (common name) (2)
            Length: 13
            Text: User Name <-- USER NAME IN PLAINTEXT
            Type: TOOL (name/version of source app) (6)
            Length: 9
            Text: GStreamer
            Type: END (0)
[RTCP frame length check: OK - 84 bytes]
Comment 2 Vincent Penquerc'h 2012-01-20 16:24:56 UTC
I see where this is done.
From http://freesoft.org/CIE/RFC/1889/25.htm, I gather this is just informative, so I see two solutions:
- a bitflags property selecting which information to include, being 0 by default.
- strings properties for each of these entries, "" by default.
Comment 3 Olivier Crête 2012-01-20 17:27:32 UTC
We may want to default to something useless yet valid like "user@" or "gstreamer@".
Comment 4 Tim-Philipp Müller 2012-01-21 12:53:52 UTC
Marking as blocker for now.

The only thing I'm worried is whether we use these fields ourselves to map/find stuff in places - do you know if that's the case or not Olivier? (But even if so, we could still send hashes or random identifiers instead I guess?)
Comment 5 Tim-Philipp Müller 2012-01-23 13:48:47 UTC
commit a476d529d2f2d6a2c4a7008387de7cd427581b5f
Author: Tim-Philipp Müller <tim.muller@collabora.co.uk>
Date:   Mon Jan 23 13:15:46 2012 +0000

    rtpmanager: don't reveal the user's username, hostname or real name by default
    
    Send a randomly made-up user@hostname as CNAME and don't
    send a NAME at all by default.
    
    https://bugzilla.gnome.org/show_bug.cgi?id=668320
Comment 6 Olivier Crête 2012-01-23 17:34:31 UTC
I believe it's already user settable, so I don't know of any code that assumes the value. That said, the part after @ should probably be stable per machine, so maybe we want to hash the hostname or the dbus machine id or something like that.