Evil OpenSSH servers can steal your private login keys to other systems – patch now

[Batu69]

And consider regenerating your keys just in case

Malicious OpenSSH servers can silently steal people's private SSH keys as they try to login, it emerged today.

This means criminals who compromise one server can secretly grab keys needed to log into other systems from a user's computer – allowing crooks to jump from server to server.

 

The security cockup, present in the default configuration of OpenSSH, has been patched today, and all users and administrators are urged to update as soon as possible.

SSH keys are an alternative to passwords: you generate a public and private key pair, give the remote server your public key, and keep the private key on your own computer. Then when you next login, the SSH server and client use the keys to identify and authorize you. If someone swipes your private key, they can log in as you – it's as if they stole your password.

 

"When there's a serious security bug in the remote access tool used by 70-plus per cent of the servers in the world, people sit up and take notice," said Kenn White, co-director of the Open Crypto Audit Project.

 

The bug lies in versions 5.4 to 7.1 of the OpenSSH client, specifically in a little-known default-enabled feature called roaming that allows you to restart an SSH session after the connection has been interrupted.

 

The roaming code contains an information sharing flaw (CVE-2016-0777) and a mildly harmless buffer overflow (CVE-2016-0778) blunder.

The experimental roaming feature is not supported by servers – but malicious or hacked systems could implement it server-side and exploit the info-leak vulnerability.

 

To cope with a connection break, the client keeps a buffer in memory that contains the user's private keys. According an excellent analysis by the flaw's finders Qualys, it is possible to extract the cryptographic data, either partially or completely.

Exploitation

"We initially believed that this information leak in the OpenSSH client's roaming code would not allow a malicious SSH server to steal the client's private keys," the Qualys team explained today.

 

"We eventually identified three reasons why, in our experiments, we were able to partially or completely retrieve the OpenSSH client's private keys through this information leak (depending on the client's version, compiler, operating system, heap layout, and private keys)."

 

Crucially, Qualys added:

Quote

This information leak may have already been exploited in the wild by sophisticated attackers, and high-profile sites or users may need to regenerate their SSH keys accordingly.

 

One bright spot is that passphrase-encrypted SSH keys are leaked in their encrypted form and must be cracked offline. Not everyone protects their keys using a passphrase, however.

The buffer overflow issue is less serious, since it can't be exploited in the default configuration of the OpenSSH client software. Instead it relies on the use of ProxyCommand, and either ForwardAgent (-A) or ForwardX11 and is unlikely to be exploited.

 

To kill off the client info-leak bug, patch your software, and add UseRoaming no to your SSH config files.

"For OpenSSH >= 5.4 the vulnerable code in the client can be completely disabled by adding 'UseRoaming no' to the global ssh_config(5) file, or to user configuration in ~/.ssh/config, or by passing -oUseRoaming=no on the command line," said the OpenSSH team in an advisory.

 

The OpenSSH team has released version 7.1p2 that fixes the issue and software houses are scrambling to lock down this latest threat. The latest builds of FreeBSD and OpenBSD have already been patched, as have Debian, Ubuntu, and Red Hat Enterprise Linux.

 

The problem is that it's now down to IT managers to make the necessary software upgrades, and as we've seen with Heartbleed that can take a while. In the meantime an attacker can either set up honeypot servers or (more likely) compromise existing legitimate OpenSSH servers, and start harvesting keys.

 

PS: 32-bit TLS servers written in Go need to be rebuilt because they may leak their private keys.

 

Article source

[brain_death]

• Quote

   

  • Red Hat Enterprise Linux 4, 5, and 6 are not affected by this flaw because they include OpenSSH versions older than 5.4, and hence do not implement the roaming feature.
  • Red Hat Enterprise Linux 7 since version 7.1 has provided OpenSSH 6.6 for which the default configuration is not affected by this flaw. OpenSSH 6.6 is only vulnerable to this issue when used with certain non-default ProxyCommand settings. Security update RHSA-2016-0043 corrects this issue.
  • Red Hat Enterprise Linux 7 prior to version 7.1 (released in March 2015) provides OpenSSH 6.4 and is impacted regardless of the use of the ProxyCommand settings. The OpenSSH packages were updated from version 6.4 to version 6.6 in Red Hat Enterprise Linux 7.1 via RHSA-2015:0425.

   

   

• Quote

   

  https://access.redhat.com/articles/2123781

   

   

[steven36]

OpenSSH updated 6.6  on almost all distros 2  days ago .  On  Linux most thereats  by the time news is posted  are  patched already unless you use some distro no longer supported  then that's you're own idiotic doings. Threats on Linux are patched much faster than windows  because its open source . You dont have to wait up  to 3 mths  for Microsoft to patch them .

 

for Linux Mint it was patched

http://www.ubuntuupdates.org/package/core/trusty/universe/updates/openssh

 

Quote

 

openssh 1:6.6p1-2ubuntu2.4 source package in Ubuntu

Changelog

openssh (1:6.6p1-2ubuntu2.4) trusty-security; urgency=medium

  * SECURITY UPDATE: information leak and overflow in roaming support
    - debian/patches/CVE-2016-077x.patch: completely disable roaming option
      in readconf.c.
    - CVE-2016-0777
    - CVE-2016-0778

 -- Marc Deslauriers <email address hidden>  Wed, 13 Jan 2016 10:48:19 -0500

 

https://launchpad.net/ubuntu/+source/openssh/1:6.6p1-2ubuntu2.4