Socat vulnerability shows that crypto backdoors can be hard to spot

03.02.2016
Developers of the Socat networking tool have fixed a cryptographic flaw that left communications open to eavesdropping for over a year. The error is so serious that members of the security community believe it could be an intentional backdoor.

Socat is a more complex and feature-rich reimplementation of netcat, a cross-platform networking service that can establish outbound and inbound connections on different ports and protocols. It is also a popular tool for network debugging.

Socat can create encrypted connections using the Diffie-Hellman (DH) key exchange mechanism, which fundamentally relies on a prime number to derive the shared secrets for key exchanges. It turns out that the 1024-bit DH parameter used by Socat was not actually a prime number.

"The effective cryptographic strength of a key exchange using these parameters was weaker than the one one could get by using a prime p," the Socat developers said in an advisory. "Moreover, since there is no indication of how these parameters were chosen, the existence of a trapdoor that makes possible for an eavesdropper to recover the shared secret from a key exchange that uses them cannot be ruled out."

The problem was fixed in versions 1.7.3.1 and 2.0.0-b9 of Socat, which replace the old DH parameter with 2048-bit one that is actually a prime number. Nevertheless, this sparked a debate in the security community as to whether this cryptographic implementation error was intentional.

The addition of the non-prime parameter was tracked down to a January 2015 patch submitted by a developer named Zhigang Wang and accepted by the Socat developers. Based on the patch comments, Zhigang wanted to fix the tool's non-compliance with the Federal Information Processing Standards (FIPS) which require that 1024-bit DH parameters are used. At the time, Socat was using a 512-bit DH prime.

Whether the flaw was intentional or not, its existence does highlight the ease with which cryptographic backdoors can be introduced into projects without maintainers noticing. Checking whether a 1024-bit number is prime is doable, but is not exactly straightforward. And since this is not something that gets changed often developers don't add automated checks for it.

Random number generators are also a critical component of cryptographic systems that, if not implemented correctly, can open up so-called encryption backdoors and over time weak random number generators have been found in many projects.

Lucian Constantin

Zur Startseite