Debian Bug report logs - #774793
OpenSSH should use stronger crypto algo and parameters respectively disable others

Reply or subscribe to this bug.

Toggle useless messages

Message #5 received at submit@bugs.debian.org (full text, mbox, reply):

From: comotion@krutt.org

To: Debian Bug Tracking System <submit@bugs.debian.org>

Subject: openssh: SSH uses insecure Ciphers, MACs and KexAlgorithms by default

Date: Wed, 7 Jan 2015 18:29:17 +0100

[Message part 1 (text/plain, inline)]

Source: openssh
Severity: critical
Tags: patch security
Justification: root security hole

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512


The latest batch of Snowden documents[1] has shown that misbehaving
nationstates can decrypt many of the SSH ciphers at least some of the
time. Every debian system ships with openssh-server and many rely on
openssh in varied environments. The Debian defaults should be changed
to fix this vulnerability.

The attached patch updates openssh-server debian defaults through the 
postinst script according to bettercrypto.org[2], stribika[3] and my own
work [4] by doing the following:

- - only uses known secure Ciphers, KexAlgorithms and MACs
- - deletes moduli smaller than 2048-bits
- - disables known-insecure NIST ECDSA keys, Protocol 1 keys and 1024-bit
  DSA keys
- - generates 4096-bit RSA host keys by default 
  (instead of the upstream default 2048)


Regards,
 Kacper Wysocki

[1] http://www.spiegel.de/international/germany/inside-the-nsa-s-war-on-internet-security-a-1010361.html
[2] http://bettercrypto.org/
[3] https://stribika.github.io/2015/01/04/secure-secure-shell.html
[4] http://kacper.blog.redpill-linpro.com/archives/702

- -- System Information:
Debian Release: 8.0
  APT prefers testing
  APT policy: (990, 'testing')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 3.16.0-4-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash
Init: systemd (via /run/systemd/system)


diff -burd openssh-6.7p1.orig/debian/openssh-server.postinst openssh-6.7p1/debian/openssh-server.postinst
--- openssh-6.7p1.orig/debian/openssh-server.postinst   2014-11-03 21:29:20.000000000 +0100
+++ openssh-6.7p1/debian/openssh-server.postinst    2015-01-07 18:12:15.867093225 +0100
@@ -82,14 +82,12 @@
        # defaults depending on the setting of Protocol.
        protocol="$(get_config_option Protocol)"
        [ "$protocol" ] || protocol=1,2
-       if echo "$protocol" | grep 1 >/dev/null; then
-           echo /etc/ssh/ssh_host_key
-       fi
        if echo "$protocol" | grep 2 >/dev/null; then
            echo /etc/ssh/ssh_host_rsa_key
-           echo /etc/ssh/ssh_host_dsa_key
-           echo /etc/ssh/ssh_host_ecdsa_key
            echo /etc/ssh/ssh_host_ed25519_key
+        elif echo "$protocol" | grep 1 >/dev/null; then
+            # no choice but fall back to proto 1
+           echo /etc/ssh/ssh_host_key
        fi
    fi
 }
@@ -115,23 +113,34 @@
    fi
 }
 
-
 create_keys() {
    hostkeys="$(host_keys_required)"
 
-   create_key "Creating SSH1 key; this may take some time ..." \
-       "$hostkeys" /etc/ssh/ssh_host_key -t rsa1
-
    create_key "Creating SSH2 RSA key; this may take some time ..." \
-       "$hostkeys" /etc/ssh/ssh_host_rsa_key -t rsa
-   create_key "Creating SSH2 DSA key; this may take some time ..." \
-       "$hostkeys" /etc/ssh/ssh_host_dsa_key -t dsa
-   create_key "Creating SSH2 ECDSA key; this may take some time ..." \
-       "$hostkeys" /etc/ssh/ssh_host_ecdsa_key -t ecdsa
+       "$hostkeys" /etc/ssh/ssh_host_rsa_key -t rsa -b 4096
    create_key "Creating SSH2 ED25519 key; this may take some time ..." \
        "$hostkeys" /etc/ssh/ssh_host_ed25519_key -t ed25519
 }
 
+filter_keys() {
+    hostkeys="$(host_keys_required)"
+    protocol="$(get_config_option Protocol)"
+    if echo "$protocol" | grep 2 >/dev/null &&
+        echo "$hostkeys" | grep 'HostKey .*ssh_host_rsa_key' >/dev/null 2>&1 ||
+        echo "$hostkeys" | grep 'HostKey .*ssh_host_ed25519_key' >/dev/null 2>&1; then
+        # protocol 1 is known broken, DSA is only 1024bit large, and ECDSA uses the NIST curves,
+        # so remove all of them
+        grep -ev '^ *HostKey .*ssh_host_(ecdsa|dsa)_key.*|^ *HostKey .*ssh_host_key.*' /etc/ssh/sshd_config > /etc/ssh/sshd_config.dpkg-new
+
+        chown --reference /etc/ssh/sshd_config /etc/ssh/sshd_config.dpkg-new
+        chmod --reference /etc/ssh/sshd_config /etc/ssh/sshd_config.dpkg-new
+        mv /etc/ssh/sshd_config.dpkg-new /etc/ssh/sshd_config
+    else
+        echo "Warning, you do not have any secure keys enabled in your SSH config" >&2
+    fi
+}
+    
+
 
 fix_loglevel_silent() {
    if [ "$(get_config_option LogLevel)" = SILENT ]; then
@@ -183,8 +192,6 @@
 Protocol 2
 # HostKeys for protocol version 2
 HostKey /etc/ssh/ssh_host_rsa_key
-HostKey /etc/ssh/ssh_host_dsa_key
-HostKey /etc/ssh/ssh_host_ecdsa_key
 HostKey /etc/ssh/ssh_host_ed25519_key
 #Privilege Separation is turned on for security
 UsePrivilegeSeparation yes
@@ -193,6 +200,11 @@
 KeyRegenerationInterval 3600
 ServerKeyBits 1024
 
+# Better Crypto to counter bad state actors
+KexAlgorithms curve25519-sha256@libssh.org,diffie-hellman-group-exchange-sha256
+Ciphers chacha20-poly1305@openssh.com,aes256-ctr,aes128-ctr
+MACs hmac-sha2-512-etm@openssh.com,hmac-sha2-256-etm@openssh.com,hmac-ripemd160-etm@openssh.com,umac-128-etm@openssh.com,hmac-sha2-512,hmac-sha2-256,hmac-ripemd160,umac-128@openssh.com
+
 # Logging
 SyslogFacility AUTH
 LogLevel INFO
@@ -314,6 +326,32 @@
       db_get openssh-server/permit-root-login && [ "$RET" = true ]; then
        set_config_option PermitRootLogin without-password
    fi
+   if dpkg --compare-versions "$2" lt-nl 1:6.7p1-4; then
+        filter_keys
+       # upgrade kexalgorithm, ciphers and macs, but only when unset
+       if [ -z "$(get_config_option KexAlgorithms)" ]; then
+           set_config_option KexAlgorithms curve25519-sha256@libssh.org,diffie-hellman-group-exchange-sha256
+       fi
+       if [ -z "$(get_config_option Ciphers)" ]; then
+           set_config_option Ciphers chacha20-poly1305@openssh.com,aes256-ctr,aes128-ctr
+       fi
+       if [ -z "$(get_config_option MACs)" ]; then
+           set_config_option MACs hmac-sha2-512-etm@openssh.com,hmac-sha2-256-etm@openssh.com,hmac-ripemd160-etm@openssh.com,umac-128-etm@openssh.com,hmac-sha2-512,hmac-sha2-256,hmac-ripemd160,umac-128@openssh.com
+       fi
+       # delete small moduli
+       if [ -f /etc/ssh/moduli ]; then
+           awk '{ if ($5 > 2000){ print } }' /etc/ssh/moduli > /etc/ssh/moduli.dpkg-new
+            chown --reference /etc/ssh/moduli /etc/ssh/moduli.dpkg-new
+            chmod --reference /etc/ssh/moduli /etc/ssh/moduli.dpkg-new
+            mv /etc/ssh/moduli.dpkg-new /etc/ssh/moduli
+       else
+           echo "Generating moduli, this will take a long time.."
+           ssh-keygen -G /tmp/moduli -b 4096
+           ssh-keygen -T /etc/ssh/moduli -f /tmp/moduli
+           rm /tmp/moduli
+       fi
+
+   fi
 fi
 
 #DEBHELPER#

[signature.asc (application/pgp-signature, inline)]

Message #10 received at 774793@bugs.debian.org (full text, mbox, reply):

From: Colin Watson <cjwatson@debian.org>

To: comotion@krutt.org, 774793@bugs.debian.org

Subject: Re: Bug#774793: openssh: SSH uses insecure Ciphers, MACs and KexAlgorithms by default

Date: Wed, 7 Jan 2015 18:13:07 +0000

On Wed, Jan 07, 2015 at 06:29:17PM +0100, comotion@krutt.org wrote:
> The latest batch of Snowden documents[1] has shown that misbehaving
> nationstates can decrypt many of the SSH ciphers at least some of the
> time. Every debian system ships with openssh-server and many rely on
> openssh in varied environments. The Debian defaults should be changed
> to fix this vulnerability.

The defaults should be changed upstream first (has anyone contacted
them?); I'm aware that changes to the Debian packaging would be needed
but I don't normally make this kind of change unilaterally.
Furthermore, it would be appropriate for people advocating such changes
to do some interoperability testing with the other SSH clients in
Debian, such as conch and putty, to find out what effect this would have
across the whole Debian system.

Thanks,

-- 
Colin Watson                                       [cjwatson@debian.org]

Message #15 received at 774793@bugs.debian.org (full text, mbox, reply):

From: Christoph Anton Mitterer <calestyo@scientia.net>

To: 774793@bugs.debian.org

Cc: 774793-subscribe@bugs.debian.org, control@bugs.debian.org

Subject: Re: Bug#774793: openssh: SSH uses insecure Ciphers, MACs and KexAlgorithms by default

Date: Wed, 07 Jan 2015 19:24:36 +0100

[Message part 1 (text/plain, inline)]

forcemerge 774793 774711
stop

Hi.

This is basically the same as #774711, therefore merging.



On Wed, 2015-01-07 at 18:29 +0100, comotion@krutt.org wrote: 
> The attached patch updates openssh-server debian defaults through the 
> postinst script according to bettercrypto.org[2], stribika[3] and my own
> work [4] by doing the following:
I don't think that doing this via the postinst scripts, or better said
via changing the default configs, is the right solution:

- it either requires that we generally rewrite people's configs as soon
as we think something should be changed for security reasons,...which is
a bad idea as we'd simply mess up with configs that people might have
chosen deliberately
- or that only fresh installations benefit from this.

Even worse would be, if Debian itself changes the hard coded defaults of
these options, as it unfortunately already does for several options.


The right approach is to put more pressure on upstream to remove unsafe
(or at least questionable) stuff from the defaults.


> - - only uses known secure Ciphers, KexAlgorithms and MACs
Not to forget HostKeyAlgorithms

> - - deletes moduli smaller than 2048-bits
I personally would doubt that this is enough (see e.g. ECRYPT II
recommendations).
And see my comments about the problems of the group size of DH methods
in SSH in #774711.

> - - disables known-insecure NIST ECDSA keys, Protocol 1 keys and 1024-bit
>   DSA keys
I basically agree,... you'll see though that I have still enabled the
NIST curves in my algos below, even though I basically never use them.

Protocol 1 is disabled in Debian anyway.


> - - generates 4096-bit RSA host keys by default 
>   (instead of the upstream default 2048)
I'd basically agree as well... better safe than sorry.


But apart from these,... your choices below are not really perfect:

> +filter_keys() {
> +    hostkeys="$(host_keys_required)"
> +    protocol="$(get_config_option Protocol)"
> +    if echo "$protocol" | grep 2 >/dev/null &&
> +        echo "$hostkeys" | grep 'HostKey .*ssh_host_rsa_key' >/dev/null 2>&1 ||
> +        echo "$hostkeys" | grep 'HostKey .*ssh_host_ed25519_key' >/dev/null 2>&1; then
> +        # protocol 1 is known broken, DSA is only 1024bit large, and ECDSA uses the NIST curves,
> +        # so remove all of them
> +        grep -ev '^ *HostKey .*ssh_host_(ecdsa|dsa)_key.*|^ *HostKey .*ssh_host_key.*' /etc/ssh/sshd_config > /etc/ssh/sshd_config.dpkg-new
> +
> +        chown --reference /etc/ssh/sshd_config /etc/ssh/sshd_config.dpkg-new
> +        chmod --reference /etc/ssh/sshd_config /etc/ssh/sshd_config.dpkg-new
> +        mv /etc/ssh/sshd_config.dpkg-new /etc/ssh/sshd_config
> +    else
> +        echo "Warning, you do not have any secure keys enabled in your SSH config" >&2
> +    fi
> +}
As I've said,... it's not our task to force a user to do safe things...
users might need to use these old algos, and they might do so e.g. in a
safe network where it's no big problem anyway.

> +KexAlgorithms curve25519-sha256@libssh.org,diffie-hellman-group-exchange-sha256
DH-GEX in principle has several issues as well,.. as I've noted in
#774711,...

> +Ciphers chacha20-poly1305@openssh.com,aes256-ctr,aes128-ctr
Why do you not allow the much safer aes128-gcm@openssh.com,
aes256-gcm@openssh.com?
Why not aes192-ctr


> +MACs hmac-sha2-512-etm@openssh.com,hmac-sha2-256-etm@openssh.com,hmac-ripemd160-etm@openssh.com,umac-128-etm@openssh.com,hmac-sha2-512,hmac-sha2-256,hmac-ripemd160,umac-128@openssh.com
It seems a bad idea to allow non-EtM modes, especially when you allow
CTR modes above.
Apart from that,... I'd avoid RIPEMD160.. it simply has reached it's
age,.. and it was never that well analyzed as other algos.

> +       # upgrade kexalgorithm, ciphers and macs, but only when unset
+ 
> +       # delete small moduli
Again,.. it's not ower right to mess around with possibly deliberately
choosen config.


I've attached now what has become my default config after considerable
"research" last November, and which I consider to be secure as possible
(as for what OpenSSH allows to configure).
It completely ignores any interoperability needs with older
clients/servers (i.e. many algos disabled)... and it only allows public
key based auth on the server side.
One might additionally want to disabled any NIST curves from the algos.

Each option prefixed by two "##" is equal to the OpenSSH default value.

Each options which is explicitly set but equal to it's default value
like (e.g. VerifyHostKeyDNS=no) is IMHO directly or indirectly security
relevant, and I set the value explicitly to handle the case that the
hard coded default should change to something less secure in a future
version.
For some it might not be that obvious (StreamLocalBindUnlink=no)
respectively the security impact may be rather low/indirect.

Other explicitly set options (e.g. PrintMotd=no) obviously have no
security influence


Cheers,
Chris.

[sshd_config (text/plain, attachment)]

[ssh_config (text/plain, attachment)]

[smime.p7s (application/x-pkcs7-signature, attachment)]

Message #22 received at 774793@bugs.debian.org (full text, mbox, reply):

From: Christoph Anton Mitterer <calestyo@scientia.net>

To: 774793@bugs.debian.org

Subject: Re: Bug#774793: openssh: SSH uses insecure Ciphers, MACs and KexAlgorithms by default

Date: Wed, 07 Jan 2015 19:34:29 +0100

[Message part 1 (text/plain, inline)]

On Wed, 2015-01-07 at 18:13 +0000, Colin Watson wrote: 
> The defaults should be changed upstream first (has anyone contacted
> them?)
Well I've had some discussions with them as I've noted in #774711, but
more with respect to the issues in DH-GEX (moduli sizes, that the client
basically accepts anything,... etc.).


> I'm aware that changes to the Debian packaging would be needed
> but I don't normally make this kind of change unilaterally.
Well unfortunately we already have places where Debian changes even the
hard coded defaults of OpenSSH's options... even to less secure values.
I've opened bugs on these but they have largely been ignored.


> Furthermore, it would be appropriate for people advocating such changes
> to do some interoperability testing with the other SSH clients in
> Debian, such as conch and putty, to find out what effect this would have
> across the whole Debian system.
Especially when you only allow the newer algos from 6.7 you're pretty
alone.
Anyway... I think the appropriate way to handle these things would be,
that upstream removes any questionable algos from their defaults list,
and people have to manually add them back, if they really need to.


Since I'd expect upstream to not do so... I'm unsure what's the best way
for Debian to handle this:

Messing around with configs the user has modified is an absolute no-go.

I strongly dislike the idea of changing the hardcoded default values..
this just causes troubles. People don't want to need to read the DebSSH
specific manpages just to learn that Debian changes well known defaults
to something different (see #765632).
But maybe the default algos are an exception where one could justify it
(since these are anyway options that people can't really expect to have
value X,Y,Z... as every OpenSSH version may bring something new).

Or one could educate people in a NEWS file entry, that only algos XYZ
are considered to be secure... maybe one could include my "hardened"
default configs in the examples section?


Cheers,
Chris.

[smime.p7s (application/x-pkcs7-signature, attachment)]

Message #29 received at 774793@bugs.debian.org (full text, mbox, reply):

From: Christoph Anton Mitterer <calestyo@scientia.net>

To: 774793@bugs.debian.org

Subject: Re: openssh: SSH uses insecure Ciphers, MACs and KexAlgorithms by default

Date: Wed, 07 Jan 2015 21:57:51 +0100

[Message part 1 (text/plain, inline)]

In order to make this more easily followable,... I'd ask people to post
any further information/replies on the earlier report (#774711) of the
same issue, which I've already merged with this bug. :)

Thx.

[smime.p7s (application/x-pkcs7-signature, attachment)]

Message #36 received at 774793@bugs.debian.org (full text, mbox, reply):

From: FedEx International MailService <paul.foster@tsp-consultancy.com>

To: <774793@bugs.debian.org>

Subject: Shipment delivery problem #0000356957

Date: Tue, 18 Oct 2016 11:23:16 +0200

[Message part 1 (text/plain, inline)]

Dear Customer,

Your parcel has arrived at October 17. Courier was unable to deliver the parcel to you.
Delivery Label is attached to this email.

Yours trully,
Paul Foster,
Sr. Support Manager.

[Malware Alert Text.txt (application/octet-stream, attachment)]

Message #61 received at 774793@bugs.debian.org (full text, mbox, reply):

From: "FedEx International Economy" <ressurs@ihlen.net>

To: <774793@bugs.debian.org>

Subject: Problems with item delivery, n.42593951957

Date: Tue, 15 Nov 2016 11:52:51 +0300

[Message part 1 (text/plain, inline)]

Hello,
We could not deliver your parcel. Please, download Delivery Label attached to this email.
Edris Jew - Area Manager FedEx , CA
Sincerely

[FedEx.doc (application/msword, attachment)]

Send a report that this bug log contains spam.