CVE-2014-5075 MitM Vulnerability in the Smack XMPP Library for Java

Smack <http://www.igniterealtime.org/projects/smack/&gt; is an Open Source
XMPP (Jabber) client library for instant messaging and presence written
in Java. Smack prior to version 4.0.2 is vulnerable to TLS
Man-in-the-Middle attacks, as it fails to check if the server
certificate matches the hostname of the connection.

Affected versions

• Smack 4.0.0 and 4.0.1 are vulnerable.
• Smack 2.x and 3.x are vulnerable if a custom `SSLContext` is
  supplied via `connectionConfiguration.setCustomSSLContext()`.

Details

Smack is using Java's `SSLSocket`, which checks the peer certificate
using an `X509TrustManager`, but does not perform hostname verification.
Therefore, it is possible to redirect the traffic between a Smack-using
application and a legitimate XMPP server through the attacker's server,
merely by providing a valid certificate for a domain under the
attacker's control.

In Smack versions 2.2.0 to 3.4.1, a custom `ServerTrustManager`
implementation was used, which was supplied with the connection's server
name, and performed hostname verification. However, it failed to verify
the basicConstraints and nameConstraints of the certificate chain
(CVE-2014-0363, http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2014-0363&#41;
and has been removed in Smack 4.0.0.

Applications using Smack 2.2.0 to 3.4.1 with a custom `TrustManager` did
not benefit from `ServerTrustManager` and are vulnerable as well, unless
their own `TrustManager` implementation explicitly performs hostname
verification.

Mitigation

Users of the Smack library are advised to upgrade to Smack 4.0.2, and
then use `connectionConfiguration.setHostnameVerifier()` with a
reasonable `HostnameVerifier` implementation. A proper hostname verifier
MUST be configured to close the vulnerability.

For Smack 3.x users, a backported commit has been created:

https://github.com/ge0rg/smack/commit/8d483b25bda7ae86a3f3e83217c2add6d710798a

Here, a `HostnameVerifier` implementation needs to be
supplied via `connectionConfiguration.setHostnameVerifier()` as well.

When using the official JRE, the internal class
`sun.security.util.HostnameChecker` can be wrapped as described
here:

http://kevinlocke.name/bits/2012/10/03/ssl-certificate-verification-in-dispatch-and-asynchttpclient/

If Apache's HttpClient library is available, its `StrictHostnameVerifier` can
be used.

On Android, MemorizingTrustManager provides both certificate checking and
hostname verification with interactive fallback, allowing the user to decide
about the trustworthiness of a server:

https://github.com/ge0rg/MemorizingTrustManager/

Affected Applications

Smack is a library used by different applications. Therefore, the
authors of the following Smack-based applications have been contacted to
coordinate updated releases:

• ChatSecure (fixed in 13.2.0-beta1)
• GTalkSMS (contacted on 2014-07-28)
• MAXS (fixed in 0.0.1.18)
• yaxim and Bruno (fixed in 0.8.8)
• undisclosed Android application (contacted on 2014-07-21)

The following Smack-based applications were not affected:

• TransVerse (special interest client)
• Xabber (using a custom `TrustManager` performing hostname verification)

Timeline

• 2014-07-20 Discovery of Smack vulnerability, notification of Smack
  maintainer
• 2014-07-21 Notification of vulnerable apps' authors
• 2014-07-27 Release of Smack 4.0.2
• 2014-08-01 Release of MAXS 0.0.1.18
• 2014-08-04 Release of yaxim 0.8.8
• 2014-08-05 Release of ChatSecure 13.2.0 beta 1
• 2014-08-05 Publication of this advisory

Links

Online version of advisory:
http://op-co.de/CVE-2014-5075.html

PDF version:
http://op-co.de/CVE-2014-5075.pdf

– Dr. Georg Lukas rt-solutions.de GmbH Oberlander Ufer 190a D-50968 Koln Tel. : (+49)221 93724 0 Fax : (+49)221 93724 50 Mobil: (+49)179 4176591 Web : www.rt-solutions.de