FYI. The fix for jabberd2 is here: https://github.com/Jabberd2/jabberd2/commit/aabcffae560d5fd00cd1d2ffce5d760353cf0a4d
and the bugfix release is coming. -------- Original Message -------- Subject: [Security] Vulnerability in XMPP Server Dialback Implementations Date: Tue, 21 Aug 2012 10:03:45 -0600 From: Peter Saint-Andre <stpe...@stpeter.im> Reply-To: XMPP Security <secur...@xmpp.org> To: secur...@xmpp.org As posted at http://xmpp.org/resources/security-notices/server-dialback/ ... ### Vulnerability in XMPP Server Dialback Implementations Original Release Date: 2012-08-21 Last Updated: 2012-08-21 Overview Some implementations of the XMPP Server Dialback protocol (RFC 3920 / XEP-0220) have not been checking dialback responses to ensure that validated results are correlated with requests. Description The Server Dialback protocol is a proof-of-possession technology used between XMPP servers to provide identity verification based on the Domain Name System (DNS); the basic approach is that when a receiving server accepts a server-to-server connection from an initiating server, it does not process traffic over the connection until it has verified the initiating server’s key with an authoritative DNS entry for the initiating server. Additionally, the protocol is used to negotiate whether the receiving server is accepting stanzas for the target domain. The goal of the protocol is to help prevent address spoofing on the XMPP network, which it has effectively done since deployed on the XMPP network in October 2000. There are four steps to the protocol: 1. Authorization Request: The initiating server sends a dialback key to the receiving server for a given domain pair consisting of a source domain and a target domain. 2. Verify Request: the receiving server forwards the key to the authoritative server for the domain asserted by the initiating server. 3. Verify Response: the authoritative server informs the receiving server whether the key is valid or invalid. 4. Authorization Response: the receiving server reports the result of the negotiation to the initiating server. Some XMPP server implementations have not been checking the Verify Response to ensure that the receiving server previously received an Authorization Request for the domain pair included in the Verify Response. Thus an attacking server has been able to send a Verify Response for domains that were never asserted by an initiating server, and some receiving servers would accept such domain pairs as validated. In addition, some XMPP server implementations have not been checking the Authorization Response to ensure that the initiating server previously sent an Authorization Request for the domain pair included in the Authorization Response. Thus an attacking server has been able to send an Authorization Response for domains that were never asserted by an initiating server, and some initiating servers would accept such domain pairs as validated. Impact An attacking server could spoof one or more domains in communicating with a vulnerable server implementation, thereby avoiding the protections built into the Server Dialback protocol. Solution Upgrade to corrected server code. Vendor Information Please see http://xmpp.org/resources/security-notices/server-dialback/ References https://datatracker.ietf.org/doc/rfc3920/ http://xmpp.org/extensions/xep-0220.html Credits The vulnerability has been separately discovered by multiple teams in the past. Thanks to Philipp Hancke for recently reporting it in a more public fashion. Thanks also to Dave Cridland, Tomasz Sterna, and Matthew Wild for their feedback. This report was written by Peter Saint-Andre. Feedback If you have feedback, comments, or additional information about this vulnerability, please send email to the secur...@xmpp.org discussion list. ### Peter _______________________________________________ -- Tomasz Sterna Instant Messaging Consultant : Open Source Developer http://tomasz.sterna.tv/ http://www.xiaoka.com/portfolio
