Tag Archives: OpenSSH

OpenSSH Releases Further v7.2 Security Update

On Wednesday of last week OpenSSH released version 7.2p2 which corrected a security vulnerability due to X11 forwarding (defined) commands not being correctly sanitised that could have allowed information disclosure.

Why Should These Issues Be Considered Important?
This vulnerability could have allowed an attacker that had already compromised an existing users account on a Linux system to carry out the following (usually not permitted) actions:

  • allow limited information leakage
  • file overwrite
  • port probing
  • generally expose xauth(1) which was not written with a hostile user in mind, as an attack surface
  • allow the circumventing of key or account restrictions such as sshd config or ForceCommand, authorized keys command=”…” or restricted shells (defined)

Further details of this vulnerability are provided by OpenSSH here.

How Can I Protect Myself from This Issue?
Please upgrade to OpenSSH version 7.2p2 (the most recent version at the time of writing) to resolve the security issue mentioned within this post. You can install this update by using your Linux package manager to download the necessary files for your version of OpenSSH. Steps to do this for popular Linux distributions are provided on the “Protecting Your PC” of this blog.

Thank you.

ThreatPost: OpenSSH Implementations with X11forwarding Enabled Should Heed Recent Security Update

OpenSSH Releases v7.2 Security Update

On the 29th of February OpenSSH released version 7.2 of OpenSSH which further hardened it against the Logjam attack (by increasing the minimum modulus size supported for diffie-hellman-group-exchange to 2048 bits) as well as incorporating changes initially made available in mid-January with version 7.1p2

Why Should These Issues Be Considered Important?
Further hardening OpenSSH against Logjam is important for the reasons detailed in my previous blog post on that attack.

With version 7.1p2, experimental support for client-side (where a client is the name given to computer/device being used by a person to access a server) roaming support was disabled to resolve a high severity information disclosure issue. Roaming is the name given to the ability to resume an SSH (Secure Shell, defined) connection from where it left off should a client become disconnected suddenly.

While this issue is not easy to exploit (further details provided below in the heading “How Can I Protect Myself from These Issues”) it had the potential to allow an attacker who had compromised a legitimate SSH server to obtain the credentials (username and password) of the user attempting to access the server. If the attacker controlled server had SSH private keys stored in it’s memory the attacker could have also compromised further SSH accounts.

3 other low risk security vulnerabilities detailed in the release notes were also resolved within version 7.1p2. For version 7.2, the above mentioned roaming code was removed and 2 further security issues detailed in the release notes were resolved.

How Can I Protect Myself from These Issues?
The means of authentication to the SSH server prevents the exploitation of the information disclosure issue mentioned above (fixed in version 7.1p2) by means of a man-in-the-middle attack (defined). While you are working to deploy the patch for this issue, for versions 5.4 of OpenSSH and higher the roaming code can be disabled as follows (source):

  • adding ‘UseRoaming no’ to the global ssh_config(5) file
  • or to user configuration in ~/.ssh/config
  • by passing -oUseRoaming=no on the command line

Please upgrade to OpenSSH version 7.2 (the most recent at the time of writing) to resolve all of the security issues mentioned within this post.

Thank you.

OpenSSH Releases v7.0 To Patch Security Issues

OpenSSH has released v7.0 of their popular SSH implementation. This version resolves 2 issues (1x use-after-free (defined) and 1x privilege separation weakness) in the portable version of OpenSSH and 2 further issues in the standard version.

Of the 2 remaining issues, one is a fix for the issue that I previously discussed regarding how keyboard-interactive logins can be used misused to brute-force your password. The remaining issue involves resolving an issue that could allow local attackers to write arbitrary messages to logged-in users.

Another change in this new release of OpenSSH is that this release also resolves the Logjam security issue by rejecting 1024-bit diffie hellman key exchanges.

You can install this update by using your Linux package manager to download the necessary files for your version of OpenSSH. Steps to do this for popular Linux distributions are provided on the “Protecting Your PC” of this blog. Additionally this FAQ (from the OpenBSD website) may be of assistance.

If you use OpenSSH, please install the appropriate update when you can. If OpenSSH is installed on a critical production system or systems that contain your critical data, please back up your data before installing this update in order to prevent data loss in the rare event that an update causes unexpected issues.

Thank you.

OpenSSH Potentially Vulnerable To Password Brute Force Attack

Update: 13th August 2015:
OpenSSH has released v7.0 which addresses the issue discussed in this post.

In late July a security issue with the most widely used SSH (Secure Shell, defined) implementation namely OpenSSH for Linux based systems was documented on the Full Disclosure mailing list. SSH uses port 22, TCP (see Aside (below) for a definition) or UDP (see Aside 1 of this post for a definition).

The issue involves the now less used method of keyboard-interactive login (where you type your password using a keyboard when prompted by the server). Many SSH sessions today are set up using automated secure connections (since they are automated no person is present to type the password). Instead public key cryptography (asymmetric encryption) allows you to verify your identity to the server as follows:

In order to do this, you initially create 2 keys a public and a private key. You send the public key to the server. When you wish to log into that server it will send a challenge (a cryptographic nonce) encrypted with the public key that you previously provided. You then use your private key to decrypt that nonce, re-encrypt it with your private key and send it back. The server then uses the public key to decrypt what you have sent. This verifies to the server that you do indeed possess the correct private key and are authorized to use the server. Guides on how to set up this feature are provided here and here.

Why Should This Issue With OpenSSH Be Considered Important?
On some OpenSSH installations especially FreeBSD systems have keyboard-interactive authentication enabled by default. When this is the case, you can specify via command line parameters to OpenSSH to allow for example 10000 individual keyboard devices to try to respond to the password being requested by the server you are attempting to access. This means that you will have 10000 attempts to guess the password of the server. This would allow you to execute a brute force attack to try to obtain the password.

If the password is quite weak, 10000 attempts will be more than enough to obtain/guess that password. The server does only allow you (by default) to have 2 minutes for the “login grace time” to allow you to enter your password, thus the attack would also be limited to this time, however 10000 guesses within 2 minutes is possible. When the password is obtained an attacker can then use your server with the same level of access that you have for any purpose they wish.

What is TCP?

Transmission Control Protocol (TCP) is a connection oriented transport protocol within the larger TCP/IP ((Internet Protocol) suite which provides reliable data transmission (due to error checking and re-sending of packets corrupted or not received) and preserves the order of packets that are transmitted from a source device to a destination device. TCP/IP is a suite of protocols that provides worldwide connectivity between the devices that make up the Internet.

With TCP the connection between 2 devices must be set up and torn down. This in contrast to UDP that provides a connectionless data transmission service.

How Can I Protect Myself From This Issue?

While OpenSSH 6.9 is currently available, the upcoming version 7.0 does not appear to include revised default settings to eliminate the issue discussed above. The above suggestions should keep you safe from this potential brute force attack.

Update: 13th August 2015:
OpenSSH has released v7.0 which addresses the above issue discussed in this post.

Thank you.