Security issues

[fwininger]

Description

After a complet code audit, I found lot of critical security configurations.

I suggest to be OpenSSH 3.9/3.9p1 compatible, release on 2004-08-18, and remove all insecure and weak algorithms.

Expected behavior

Be weak but not completly unsafe and backward compatible with OpenSSH 3.9/3.9p1.

Implement new algorithms.

Actual behavior

Realy unsafe, allow communication without encryption !

Key exchange algorithms

To remove

diffie-hellman-group1-sha1 :

• removed (in server) since OpenSSH 6.7, unsafe algorithm
• disabled (in client) since OpenSSH 7.0, logjam attack
• using small 1024-bit modulus
• using weak hashing algorithm

diffie-hellman-group-exchange-sha1 :

• removed (in server) since OpenSSH 6.7, unsafe algorithm
• using weak hashing algorithm

Should be remove

ecdh-sha2-nistp521 / ecdh-sha2-nistp384 / ecdh-sha2-nistp256 :

• using weak elliptic curves
• available since OpenSSH 5.7, Dropbear SSH 2013.62

NIST curves is unsecure see : https://safecurves.cr.yp.to/

Remove when curve25519-sha256@libssh is implement (see #690)

To conserve

diffie-hellman-group14-sha1 :

• only for backward compatibility
• using weak hashing algorithm
• available since OpenSSH 3.9, Dropbear SSH 0.53

diffie-hellman-group-exchange-sha256 :

• only for backward compatibility
• using custom size modulus (possibly weak)
• available since OpenSSH 4.4

To implement

curve25519-sha256@libssh.org :

• available since OpenSSH 6.5, Dropbear SSH 2013.62 (see #690)

Host-key algorithms

To remove

ssh-dss :

• removed (in server) and disabled (in client) since OpenSSH 7.0, weak algorithm
• using small 1024-bit modulus
• using weak random number generator could reveal the key
• available since OpenSSH 2.1.0, Dropbear SSH 0.28

Should be remove

ecdsa-sha2-nistp521 / ecdsa-sha2-nistp384 /ecdsa-sha2-nistp256

• using weak elliptic curves
• using weak random number generator could reveal the key

NIST curves is unsecure see : https://safecurves.cr.yp.to/

To conserve

ssh-rsa :

• available since OpenSSH 2.5.0, Dropbear SSH 0.28

ssh-ed25519:

• available since OpenSSH 6.5

encryption algorithms (ciphers)

To remove

aes256-cbc aes192-cbc aes128-cbc :

• removed (in server) since OpenSSH 6.7, unsafe algorithm
• using weak cipher mode

rijndael-cbc@lysator.liu.se :

• removed (in server) since OpenSSH 6.7, unsafe algorithm
• disabled (in client) since OpenSSH 7.2, legacy algorithm
• using weak cipher mode

blowfish-ctr / blowfish-cbc :

• removed (in server) since OpenSSH 6.7, unsafe algorithm
• disabled since Dropbear SSH 0.53
• disabled (in client) since OpenSSH 7.2, legacy algorithm
• using weak cipher mode
• using small 64-bit block size

cast128-ctr / cast128-cbc :

• removed (in server) since OpenSSH 6.7, unsafe algorithm
• disabled (in client) since OpenSSH 7.2, legacy algorithm
• using weak cipher mode
• using small 64-bit block size

3des-ctr / 3des-cbc :

• removed (in server) since OpenSSH 6.7, unsafe algorithm
• using weak cipher
• using weak cipher mode
• using small 64-bit block size

idea-cbc :

• using weak cipher mode

none :

• no comment !

To conserve

aes256-ctr aes192-ctr aes128-ctr :

• available since OpenSSH 3.7, Dropbear SSH 0.52

To implement

aes128-gcm@openssh.com / aes256-gcm@openssh.com :

• available since OpenSSH 6.2

chacha20-poly1305@openssh.com :

• available since OpenSSH 6.5
• default cipher since OpenSSH 6.9

message authentication code algorithms

To remove

hmac-sha1-96:

• removed (in server) since OpenSSH 6.7, unsafe algorithm
• disabled (in client) since OpenSSH 7.2, legacy algorithm
• using weak hashing algorithm

hmac-sha2-512-96 / hmac-sha2-256-96:

• they were removed from the specification since OpenSSH 6.0

hmac-ripemd160 / hmac-ripemd160@openssh.com:

• removed (in server) since OpenSSH 6.7, unsafe algorithm
• disabled (in client) since OpenSSH 7.2, legacy algorithm

hmac-md5 :

• removed (in server) since OpenSSH 6.7, unsafe algorithm
• disabled (in client) since OpenSSH 7.2, legacy algorithm
• using weak hashing algorithm

hmac-md5-96: none :

• no comment !

To conserve

hmac-sha1:

• only for backward compatibility
• using encrypt-and-MAC mode
• using weak hashing algorithm
• available since OpenSSH 2.1.0, Dropbear SSH 0.28

hmac-sha2-512 / hmac-sha2-256 :

• using encrypt-and-MAC mode
• available since OpenSSH 5.9, Dropbear SSH 2013.56

To implement

umac-128-etm@openssh.com :

• available since OpenSSH 6.2

hmac-sha2-256-etm@openssh.com:

• available since OpenSSH 6.2

hmac-sha2-512-etm@openssh.com:

• available since OpenSSH 6.2

[fwininger]

@mfazekas : if you are ok with the analysis, I push some PR to secure the code. I keep the less weak algorithm to be backword compatible with OpenSSH release in 2004. I think it's good enough.

I prefer Bernstein's algorithms rather than this from the NSA (NIST P-521), however at the moment I agree to leave them in the code.

[mfazekas]

@fwininger sorry i don't have much time this weekend or over next week.

I'm all for removing unsecure algs with default config. Not sure about removing all unsecure algs from the code. I think it would be great to be compatible, with tweaked config (something likesecure: :insecure) with very old versions of openssh.

For example vagrant uses net-ssh it would desirable for vagrant (again with some flag like secure: :insecure) to be able to connect to a very old vm image.

[fwininger]

Ok, we can definitively manage that.

This code have already some options (key:, hmac:...) to specified a list of methods. So I suggest to remove by default unsecure algos and pass the list of algo with the parameter.

Example for hmac:

Net::SSH::Transport::HMAC::INSECURE = %w[all_algs]
Net::SSH::Transport::HMAC::DEFAULT= %w[only_secure_algs]

# specify all algs
Net::SSH.start('localhost', 'root', password: '', hmac: Net::SSH::Transport::HMAC::INSECURE)

# by default hmac = Net::SSH::Transport::HMAC::DEFAULT

[mfazekas]

Thanks, sure that works, if there is any way to use deprecated algs that's fine it doesn't have to be convient. We can also add a warning that that alg is going to be removed in next vers and if no complaint we can remove in next major version.

[fwininger]

According to #709, to be backward compatible just add the existing option : append_all_supported_algorithms: true

[fwininger]

Update of the current progress

Key exchange algorithms

Should be remove

ecdh-sha2-nistp521 / ecdh-sha2-nistp384 / ecdh-sha2-nistp256 :

• using weak elliptic curves
• available since OpenSSH 5.7, Dropbear SSH 2013.62

NIST curves is unsecure see : https://safecurves.cr.yp.to/

To implement

Nothing more

Host-key algorithms

Should be remove

ecdsa-sha2-nistp521 / ecdsa-sha2-nistp384 /ecdsa-sha2-nistp256

• using weak elliptic curves
• using weak random number generator could reveal the key

NIST curves is unsecure see : https://safecurves.cr.yp.to/

To implement

rsa-sha2-256, rsa-sha2-512 (see issue #712)

encryption algorithms (ciphers)

To implement

aes128-gcm@openssh.com / aes256-gcm@openssh.com :

• available since OpenSSH 6.2

chacha20-poly1305@openssh.com :

• available since OpenSSH 6.5
• default cipher since OpenSSH 6.9

message authentication code algorithms

To implement

nothing more

[fwininger]

https://www.blackhatethicalhacking.com/news/openssh-to-deprecate-sha-1-logins-due-to-security-risk/

[mfazekas]

See also #773

[fwininger]

Update of the current progress

Key exchange algorithms

Should be remove

ecdh-sha2-nistp521 / ecdh-sha2-nistp384 / ecdh-sha2-nistp256 :

• using weak elliptic curves
• available since OpenSSH 5.7, Dropbear SSH 2013.62

NIST curves is unsecure see : https://safecurves.cr.yp.to/

To implement

• sntrup761x25519-sha512@openssh.com

Host-key algorithms

Should be remove

ecdsa-sha2-nistp521 / ecdsa-sha2-nistp384 /ecdsa-sha2-nistp256

• using weak elliptic curves
• using weak random number generator could reveal the key

NIST curves is unsecure see : https://safecurves.cr.yp.to/

encryption algorithms (ciphers)

To implement

aes128-gcm@openssh.com / aes256-gcm@openssh.com :

• available since OpenSSH 6.2

message authentication code algorithms

To implement

nothing more

[tisba]

I was wondering why you want to preserve key exchange with diffie-hellman-group14-sha1. AFAIK SHA-1 has exploitable weaknesses. We had Github announced removal 6 years ago), also we had Logjam, …