Oh no, you're thinking, yet another cookie pop-up. Well, sorry, it's the law. We measure how many people read us, and ensure you see relevant ads, by storing cookies on your device. If you're cool with that, hit “Accept all Cookies”. For more info and to customize your settings, hit “Customize Settings”.

Review and manage your consent

Here's an overview of our use of cookies, similar technologies and how to manage them. You can also change your choices at any time, by hitting the “Your Consent Options” link on the site's footer.

Manage Cookie Preferences
  • These cookies are strictly necessary so that you can navigate the site as normal and use all features. Without these cookies we cannot provide you with the service that you expect.

  • These cookies are used to make advertising messages more relevant to you. They perform functions like preventing the same ad from continuously reappearing, ensuring that ads are properly displayed for advertisers, and in some cases selecting advertisements that are based on your interests.

  • These cookies collect information in aggregate form to help us understand how our websites are being used. They allow us to count visits and traffic sources so that we can measure and improve the performance of our sites. If people say no to these cookies, we do not know how many people have visited and we cannot monitor performance.

See also our Cookie policy and Privacy policy.

This article is more than 1 year old

Socat slams backdoor, sparks thrilling whodunit

Year-old bug ruined crypto

Popular admin tool Socat has issued a patch for an error that's been in the code for 12 months and is so egregious some fear it could be a backdoor.

The problem, revealed here, is simple: the Socat SSL implementation uses a non-prime number as its Diffie-Hellman p parameter.

Socat is akin to the famous *nix cat command, but it's able to pipe results to and from network addresses (which is why security is essential).

As Openwall's post states: "... since there is no indication of how these parameters were chosen, the existence of a trapdoor that makes it possible for an eavesdropper to recover the shared secret from a key exchange that uses them cannot be ruled out."

Over at Hacker News, people have already started playing with the p parameter, and turned up pretty quickly that it's divisible by 271 and 13,597. The Hacker News discussion rules out a simple typo, because nobody has so far found a nearby number that is prime.

The change that introduced the vulnerability is attributed to a Chinese developer working for Oracle, Zhigang Wang, who offered the fix in this January 2015 commit.

At the time, Socat developer Gerhard Rieger said the commit was made because "Socat did not work in FIPS mode because 1024 instead of 512 bit DH prime is required. Thanks to Zhigang Wang for reporting and sending a patch."

Hacker News commenters are also complaining that the number should have been tested for primeness before the commit was allowed.

If there's some reason you can't use the patched code (linked in the Openwall post), Diffie-Hellman ciphers should be disabled for now.

Along with everyone else, The Register has contacted Zhigang Wang for comment. ®

Bootnote

Here's the offending non-prime number:

14331936439490594261714896808578599103914668374026899657956682701558096
91247024938331090743438798945866534651922222519090748320381515854480347
31101690454685781999248641772509287801359980318348021809541131200479989
22079392594151856814372197299325182316616493333479662500817485143037796
6394594186901123322297453

Obvious, really.

 

Similar topics

TIP US OFF

Send us news


Other stories you might like