Year-old crypto flaw in Socat created a potentially intentional backdoor

A backdoor has been discovered in Socat, a popular open-source network administration tool similar to Netcat, and its unclear how it hasn’t been spotted earlier or at the time the backdoor was introduced.

Socat’s many capabilities are described in this document, and among them is the capability of connecting two socat processes running on different machines.

If users want to protect the connection against unauthorized access, sniffing, data manipulation etc., they can encrypt the traffic between the two instances. That’s why the software integrates the OpenSSL library and provides SSL client and server features. And it is the implementation of this library where the problem lies.

“In the OpenSSL address implementation the hard coded 1024 bit DH p parameter was not prime. The effective cryptographic strength of a key exchange using these parameters was weaker than the one one could get by using a prime p. 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 developers explained in a security advisory announcing security updates that fix the issue.

They closed the backdoor by generating a new prime modulus p parameter, and have also increased its length to 2048 bits.

Users who for whatever reason don’t want to update these newer versions of the tool can simply disable Diffie-Hellman ciphers.

In the meantime, a discussion about the discovery has developed on Hacker News, and one of the posters tracked down the change that introduced the backdoor to a code commit from January 2015.

In the note accompanying it, the committer – developer Gerhard Rieger – thanked someone named Zhigang Wang for spotting that Socat did not work in FIPS mode because a 512 bit DH prime was used instead of a 1024 bit one, and for sending in a patch (that has been implemented).

Judging by the email address from which this person sent in various comments, he was at the time (and perhaps still is) an Oracle employee. But he’s yet to come out with an explanation of why the parameter he provided was not prime. It’s of course possible that he simply made a mistake, but it’s troublesome that it was not caught by the software developers before being added to the software’s code.