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:
- 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.
- Verify Request: the receiving server forwards the key to the authoritative server for the domain asserted by the initiating server.
- Verify Response: the authoritative server informs the receiving server whether the key is valid or invalid.
- 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
| Vendor | Product | Status | Contacted | Updated |
|---|---|---|---|---|
| Apache | Vysper | Unaffected | 2012-08-02 | 2012-08-14 |
| Apple Inc. | iChat Server | Affected | 2012-08-07 | 2012-08-09 |
| Cisco Systems, Inc. | Jabber XCP | Unaffected | 2012-08-02 | 2012-08-02 |
| Citadel | Citadel | Unaffected | 2012-08-02 | 2012-08-02 |
| CommuniGate | CommuniGate Pro | Unaffected | 2012-08-02 | 2012-08-14 |
| Coversant | SoapBox Server | Unaffected | 2012-08-02 | 2012-08-09 |
| djabberd | djabberd | Unaffected | 2012-08-02 | 2012-08-12 |
| Google Talk | Unaffected | 2012-08-02 | 2012-08-03 | |
| IBM | Lotus Sametime Gateway | Unaffected | 2012-08-09 | 2012-08-09 |
| IceWarp | IceWarp Instant Messaging Server | Unknown | 2012-08-02 | 2012-08-02 |
| igniterealtime.org | Openfire | Unaffected | 2012-08-02 | 2012-08-02 |
| inetdextra | in.jabberd | Unaffected | 2012-08-02 | 2012-08-02 |
| Isode Ltd. | M-Link | Fixed | 2012-08-02 | 2012-08-07 |
| jabberd 1.x | jabberd 1.x | Unaffected | 2012-08-02 | 2012-08-07 |
| jabberd 2.x | jabberd 2.x | Fixed | 2012-08-02 | 2012-08-08 |
| j-livesupport | Jerry Messenger | Unknown | 2012-08-02 | 2012-08-02 |
| Kwickserver | Kwickserver | Unknown | 2012-08-02 | 2012-08-02 |
| ProcessOne | ejabberd | Unaffected | 2012-08-02 | 2012-08-14 |
| Prosody | Prosody | Unaffected | 2012-08-02 | 2012-08-02 |
| psyced | psyced | Fixed | 2012-08-02 | 2012-08-02 |
| Siemens | Siemens OpenScape | Unknown | 2012-08-02 | 2012-08-02 |
| Tigase | Tigase | Fixed | 2012-08-02 | 2012-08-02 |
| Vines | Vines | Unaffected | 2012-08-02 | 2012-08-02 |
| Wokkel | Wokkel | Unaffected | 2012-08-02 | 2012-08-15 |
References
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 security@xmpp.org discussion list.
