[yocto-security] Default dropbear cipers should disallow SHA1

Wed May 8 07:34:38 PDT 2019

Hi Joseph,

I am just an outside information source, but I researched SHA1 in SSH recently.

Summary:

While it appears SHA1 in SSH is secure for now,
in the end,
I agree in general to be as restrictive as possible with algorithms for a embedded OS which might be hard to update (like a board management controller etc).

So to start off...:

Richard's concerns (check with upstream dropbear & openssh) are valid, and the specific use of SHA1 inside HMAC and DH-Group14 is not considered broken:

I'm not an expert, but these should be:

  1.  Markus Kuhn (Security Researcher @ Cambridge) and
  2.  the Dropbear and OpenSSH communities.

Here is a discussion with Markus Kuhn on HMAC-SHA1, and the second link should give you additional confidence that the use of HMAC-SHA1 as a MAC in SSH is still secure, because due to use use as a MAC inside the HMAC in HMAC-SHA1, the key is unknown to the attacker and the collision resistance of even HMAC-MD5 is more then enough (for example, even OpenSSH 7.9 supports even HMAC-MD5 as MAC):

https://github.com/stribika/stribika.github.io/issues/31#start-of-content
https://crypto.stackexchange.com/questions/26510/why-is-hmac-sha1-still-considered-secure
https://crypto.stackexchange.com/questions/9336/is-hmac-md5-considered-secure-for-authenticating-encrypted-data
http://cseweb.ucsd.edu/~mihir/papers/hmac-new.html / https://link.springer.com/article/10.1007/s00145-014-9185-x

The removal of diffie-hellman-group1-sha1 in openssh & dropbear and wasn't from SHA1 but from LogJam: https://en.wikipedia.org/wiki/Logjam_(computer_security)

Thus, while DH Group1 (1024-bit) is disabled nowadays, DH Group14 (2048 bits) is not affected by LogJam.

OTOH:

When I disable HMAC-SHA1 and diffie-hellman-group14-sha1 in my already very paranoid sshd_config algorithm whitelists, I can still login from (an up-to-date) Ubuntu 14.04 LTS installation to that host.

The only SSH client that I have which really fails to connect to that restrictive sshd then is ssh of Red Hat Enterprise Linux 5 (RHEL 5), which is really old.

To conclude the above:

I personally think that disabling SHA1 (because of collisions in an SSH MAC and DH key algorithms) does not appear to be justified,
and it seems to to this both openssh and dropbear still support it therefore.

OTOH, projects which don't need to be connected from really old SSH clients like RHEL 5, should be able to just disable it anyway to reduce future attack surface.

And especially embedded projects (like board management controllers) should have a motivation to be as paranoid as possible.

Thus, there is a valid point to be security-paranoid in a project like OpenEmbedded which is for Embedded devices which might be hard to update once they are deployed.

Please have a look at my PS below, as there are likely more algothms to consider in that regard.
Bernhard

PS, in the interest of enhanced security, I can recommend this tool to check the server:
https://github.com/arthepsy/ssh-audit

This is very paranoid, and he admitted in the discussion with Markus Kuhn that he knows that SHA1 isn't a problem, but here he explains why he warns of it anyway, just because he can:
"Yes, I know that HMAC-SHA1 does not need collision resistance but why wait? Disable weak crypto today.":

https://stribika.github.io/2015/01/04/secure-secure-shell.html

OTOH, the html above discusses (and the tool checks) a few additional points to consider when you are paranoid or want be be very future-proof.

On 08.05.19 12:05, richard.purdie at linuxfoundation.org<mailto:richard.purdie at linuxfoundation.org> wrote:

Hi Joseph,

I remember you sent patches last year related to this. As far as I
remember we never got the final version of it which just changed the
default, it looks like you have that now.

I'd probably accept such a patch into OE-Core if you send the patch to
us.

Does openssh disable that by default now? If it does the commit should
mention that as it helps show we're not losing functionality. I'd also
need to ask if anyone has discussed this with dropbear upstream as that
would need to be documented too.

Cheers,

Richard

From: Joseph Reynolds <jrey at linux.ibm.com><mailto:jrey at linux.ibm.com>

Hello.  The OpenBMC project [1] uses Yocto/poky, including the
dropbear ssh server.  We are changing the default ciphers offered to
disallow SHA1, currently in code review [2].  Would you like to make
this change or a similar change in Yocto/poky?

- Joseph

[1]: github.com/openbmc/openbmc
[2]:
https://gerrit.openbmc-project.xyz/c/openbmc/meta-phosphor/+/21028

This message, including attachments, is CONFIDENTIAL. It may also be
privileged or otherwise protected by law. If you received this email
by mistake please let us know by reply and then delete it from your
system; you should not copy it or disclose its contents to anyone.
All messages sent to and from Enea may be monitored to ensure
compliance with internal policies and to protect our business. Emails
are not secure and cannot be guaranteed to be error free as they can
be intercepted, a mended, lost or destroyed, or contain viruses. The
sender therefore does not accept liability for any errors or
omissions in the contents of this message, which arise as a result of
email transmission. Anyone who communicates with us by email accepts
these risks.

_______________________________________________
yocto-security mailing list
yocto-security at yoctoproject.org<mailto:yocto-security at yoctoproject.org>
https://lists.yoctoproject.org/listinfo/yocto-security

--
Bernhard Kaindl
SW Engineer for Control Platform Systems
----------------------------------------------------
Thales Austria GmbH
Handelskai 92, 1200 Vienna, Austria
Tel.: +43 1 27711-5095
Email: Bernhard.Kaindl at thalesgroup.com<mailto:Bernhard.Kaindl at thalesgroup.com>
www.thalesgroup.com/austria<http://www.thalesgroup.com/austria>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.yoctoproject.org/pipermail/yocto-security/attachments/20190508/0ca39f93/attachment-0001.html>