===================================================================== CERT-Renater Note d'Information No. 2011/VULN136 _____________________________________________________________________ DATE : 18/02/2011 HARDWARE PLATFORM(S) : / OPERATING SYSTEM(S) : Systems running telepathy-gabble versions prior to 0.10.5, 0.11.7, 0.8.15. ====================================================================== http://lists.freedesktop.org/archives/telepathy/2011-February/005272.html http://lists.freedesktop.org/archives/telepathy/2011-February/005273.html http://lists.freedesktop.org/archives/telepathy/2011-February/005274.html ______________________________________________________________________ I have just released telepathy-gabble version 0.10.5, the latest from the 0.10 stable branch, which contains a fix for a security issue in Jingle calls (plus one crash fix, and tweaks to the test suite). tarball: http://telepathy.freedesktop.org/releases/telepathy-gabble/telepathy-gabble-0.10.5.tar.gz signature: http://telepathy.freedesktop.org/releases/telepathy-gabble/telepathy-gabble-0.10.5.tar.gz.asc The issue theoretically allows attackers to trick Gabble into sending streamed media via a relay server selected by the attacker (as opposed to via a relay server selected by the XMPP service, or of course directly to and from the other party). The attacker sends the target a google:jingleinfo stanza containing a STUN server and a media relay of their choosing. Gabble does not check that the stanza was sent by the user's (trusted) server, and so interprets the contents. The malicious STUN server would be crafted to make the streaming implementation believe that it must use a relay (rather than being able to connect directly to the peer), and then the attacker's relay would be used. We have not constructed an exploit for this vulnerability, but we do have a test case demonstrating the bug in Gabble. All versions of the 0.8 and 0.10 stable branches of Gabble, as well as the unstable 0.11 series, are affected. Note that we do not give any security guarantees for streamed media calls, in general: audio/video data is not encrypted, so an attacker able to intercept the target's network traffic may always snoop on calls. This flaw exacerbates the situation by allowing attackers outside the network path to compromise the call. See for more details, including individual patches for each affected version of Gabble. The “Well, what's the architecture of a software in general actually!!!!!!” release. Fixes: • fd.o #31412: fix crashes during disconnection if a PEP alias request is in-flight (smcv) • Loosen an assertion to fix test failure with telepathy-glib >= 0.13.5, which releases connections' object paths sooner (smcv) • fd.o#34048: Malicious contacts can no longer trick Gabble into relaying audio/video data via a server of their choosing. (wjt, sjoerd) -- Will ______________________________________________________________________ I have just released telepathy-gabble version 0.11.7, the latest from the current 0.11 development branch, which contains (among other changes) a fix for a security issue in Jingle calls. tarball: http://telepathy.freedesktop.org/releases/telepathy-gabble/telepathy-gabble-0.11.7.tar.gz signature: http://telepathy.freedesktop.org/releases/telepathy-gabble/telepathy-gabble-0.11.7.tar.gz.asc The issue theoretically allows attackers to trick Gabble into sending streamed media via a relay server selected by the attacker (as opposed to via a relay server selected by the XMPP service, or of course directly to and from the other party). The attacker sends the target a google:jingleinfo stanza containing a STUN server and a media relay of their choosing. Gabble does not check that the stanza was sent by the user's (trusted) server, and so interprets the contents. The malicious STUN server would be crafted to make the streaming implementation believe that it must use a relay (rather than being able to connect directly to the peer), and then the attacker's relay would be used. We have not constructed an exploit for this vulnerability, but we do have a test case demonstrating the bug in Gabble. All versions of the 0.8 and 0.10 stable branches of Gabble, as well as the unstable 0.11 series, are affected. Note that we do not give any security guarantees for streamed media calls, in general: audio/video data is not encrypted, so an attacker able to intercept the target's network traffic may always snoop on calls. This flaw exacerbates the situation by allowing attackers outside the network path to compromise the call. See for more details, including individual patches for each affected version of Gabble. Dependencies: • telepathy-glib ≥ 0.13.12 is now required. Fixes: • fd.o#32390: Gabble now treats a request for a ContactSearch channel with Server set to the empty string as equivalent to not specifying a server, and rejects requests where the JID specified for Server is invalid. (wjt) • fd.o#32874: Offline contacts are now assumed to support 1–1 text channels. (jonnylamb) • fd.o#34048: Malicious contacts can no longer trick Gabble into relaying audio/video data via a server of their choosing. (wjt, sjoerd) Enhancements: • fd.o#32815: fallback-conference-server now defaults to conference.telepathy.im. Thus, if the user's server doesn't have a conference component configured, upgrading a 1-1 chat into an ad-hoc conference still works. • fd.o#11291: support for xep-0092, Software Version. (Robot101, Michael Scherer) • fd.o#33471: support for the FileTransfer.URI property. (cassidy) Regards, -- Will _________________________________________________________________________ I have just released telepathy-gabble version 0.8.15, the latest from the 0.8 old-stable branch, which contains a fix for a security issue in Jingle calls (and a fix for a JID validation bug). tarball: http://telepathy.freedesktop.org/releases/telepathy-gabble/telepathy-gabble-0.8.15.tar.gz signature: http://telepathy.freedesktop.org/releases/telepathy-gabble/telepathy-gabble-0.8.15.tar.gz.asc The issue theoretically allows attackers to trick Gabble into sending streamed media via a relay server selected by the attacker (as opposed to via a relay server selected by the XMPP service, or of course directly to and from the other party). The attacker sends the target a google:jingleinfo stanza containing a STUN server and a media relay of their choosing. Gabble does not check that the stanza was sent by the user's (trusted) server, and so interprets the contents. The malicious STUN server would be crafted to make the streaming implementation believe that it must use a relay (rather than being able to connect directly to the peer), and then the attacker's relay would be used. We have not constructed an exploit for this vulnerability, but we do have a test case demonstrating the bug in Gabble. All versions of the 0.8 and 0.10 stable branches of Gabble, as well as the unstable 0.11 series, are affected. Note that we do not give any security guarantees for streamed media calls, in general: audio/video data is not encrypted, so an attacker able to intercept the target's network traffic may always snoop on calls. This flaw exacerbates the situation by allowing attackers outside the network path to compromise the call. See for more details, including individual patches for each affected version of Gabble. The “From now on, I will live on cigarettes and black coffee.” release. Fixes: • fd.o#34048: Malicious contacts can no longer trick Gabble into relaying audio/video data via a server of their choosing. (wjt, sjoerd) • Messages from JIDS with valid, but non-ASCII, domains are no longer silently dropped. -- Will ====================================================================== ========================================================= Les serveurs de référence du CERT-Renater http://www.urec.fr/securite http://www.cru.fr/securite http://www.renater.fr ========================================================= + CERT-RENATER | tel : 01-53-94-20-44 + + 23 - 25 Rue Daviel | fax : 01-53-94-20-41 + + 75013 Paris | email: certsvp@renater.fr + =========================================================