[yocto-security] Default dropbear cipers should disallow SHA1

Wed May 8 11:18:44 PDT 2019

On 2019-05-08 09:34, KAINDL Bernhard wrote:
> 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).

Richard and Bernhard,

Thanks for your response.  I am glad we are having this discussion.

To be clear about my purpose:
The OpenBMC project has decided to remove all uses of DH group1 and SHA1 
in KEX and MAC and encryption ciphers because we have security conscious 
users.  My question is if (a) OpenBMC carries that patch, or (b) 
Yocto/poky or dropbear carries the patch (which means OpenBMC gets that 
change from its upstream projects).  I just want that answer so I know 
where to target this patch (and I understand it's a complicated 
question).

To expand on the details:
It is important to distinguish uses of the SHA1 cipher in Key Exchange 
(KEX), Message Authentication (MAC), and encryption algorithms.  They 
are different uses.  OpenBMC has decided to remove all use of SHA1 in 
MAC algorithms, not just KEX algorithms.  And that's what the patch 
referenced in this email chain does.

According to https://www.openssh.com/releasenotes.html, SHA1 KEX is 
disabled by default in the "OpenSSH 7.0/7.0p1 (2015-08-11)" release.  As 
far as I can tell, SHA1 MAC is still allowed.

According to https://matt.ucc.asn.au/dropbear/CHANGES, SHA1 KEX is 
disabled in the "2018.76 - 27 February 2018" release.  But SHA1 is still 
allowed for MACs.  As far as I know, SHA1 MACs are still allowed.

So I think SHA1 MACs are still allowed by OpenSSH and dropbear.  (As 
mentioned in this email chain, these uses are considered weak but not 
broken.)  The OpenBMC patch disables all uses of SHA1 in OpenBMC's ssh 
server, including SHA1 MACs.

To conclude: OpenBMC is tightening this security item.  I would urge 
Yocto/poky and dropbear to do the same, considering the widespread 
support for newer algorithms, but it is your decision.

- Joseph

P.S. Yes, I did fumble my previous OE-Core patch attempt.  This is a 
different set of changes.

> 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:
> 
>  	* Markus Kuhn (Security Researcher @ Cambridge) and
> 	* 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
> [3]
> https://crypto.stackexchange.com/questions/26510/why-is-hmac-sha1-still-considered-secure
> [4]
> https://crypto.stackexchange.com/questions/9336/is-hmac-md5-considered-secure-for-authenticating-encrypted-data
> [5]
> http://cseweb.ucsd.edu/~mihir/papers/hmac-new.html [6] /
> https://link.springer.com/article/10.1007/s00145-014-9185-x [7]
> 
> 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) [8]
> 
> 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 [9]
> 
> 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 [10]
> 
> 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 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>
>> 
>>> 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
>>> [1]
>>> 
[...snip...]
>> 
>> _______________________________________________
>> yocto-security mailing list
>> yocto-security at yoctoproject.org
>> https://lists.yoctoproject.org/listinfo/yocto-security [2]
> 
> --
>  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
>  www.thalesgroup.com/austria [11]
> 
> Links:
> ------
> [1] 
> https://gerrit.openbmc-project.xyz/c/openbmc/meta-phosphor/+/21028
> [2] https://lists.yoctoproject.org/listinfo/yocto-security
> [3] 
> https://github.com/stribika/stribika.github.io/issues/31#start-of-content
> [4]
> https://crypto.stackexchange.com/questions/26510/why-is-hmac-sha1-still-considered-secure
> [5]
> https://crypto.stackexchange.com/questions/9336/is-hmac-md5-considered-secure-for-authenticating-encrypted-data
> [6] http://cseweb.ucsd.edu/~mihir/papers/hmac-new.html
> [7] https://link.springer.com/article/10.1007/s00145-014-9185-x
> [8] https://en.wikipedia.org/wiki/Logjam_(computer_security)
> [9] https://github.com/arthepsy/ssh-audit
> [10] https://stribika.github.io/2015/01/04/secure-secure-shell.html
> [11] http://www.thalesgroup.com/austria
> 
> _______________________________________________
> yocto-security mailing list
> yocto-security at yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto-security