openssh unix dev - Oct 2014 - [Bug 2302] New: ssh (and sshd) should not fall back to deselected KEX algos

https://bugzilla.mindrot.org/show_bug.cgi?id=2302

            Bug ID: 2302
           Summary: ssh (and sshd) should not fall back to deselected KEX
                    algos
           Product: Portable OpenSSH
           Version: 6.7p1
          Hardware: All
                OS: All
            Status: NEW
          Severity: security
          Priority: P5
         Component: ssh
          Assignee: unassigned-bugs at mindrot.org
          Reporter: calestyo at scientia.net

Hi.

In a recent discussion[0], Christian Weisgerber pointed me to the fact
that ssh/sshd fall back to diffie-hellman-group14-sha1 if client and
server couldn't agree on parameters for DH GEX,... even when client
and/or server intentionally removed diffie-hellman-group14-sha1 from
their KEX preference list (which is like explicitly/intentionally
disabling it).

It seems that this is not exactly correct - I made some tests and it
seems that this fallback only happens if /etc/ssh/moduli is completely
empty... as long as a single entry is in the moduli file, than no
fallback seems to be performed, even if client and server couldn't
agree.
But this put all control in the hand of the server, and while one can't
protect against "evil" servers one may want to protect against servers
that are just weakly configured (without any malicious intent).


Even with the ECDH algos in places now mostly replacing the plain DH
algos, it would be nice if this fallback would no longer happen or if
it could at least be disabled (e.g. if the RFC would mandate it for a
conforming implementation).

If a user/admin removes it from his KEX algo preference list, then he
probably does so by intention and thus this shouldn't be silently
reverted again by ssh/sshd.

Further, according to e.g. the ECRYPT II recommendations,... a 2048bit
group as in group14 is only suggested for something between "legacy
standard level" and "Medium term protection",... which may not be
enough for some people.
Since its typically those people who try to disable the algo by
removing it from their preference lists, that fallback behaviour is
even more of a problem.


Of course, any such fallback mechanisms should be disabled on both
sides, ssh and sshd,... and if it happens with other algos than
diffie-hellman-group14-sha1, than that should be stopped as well.


Cheers,
Chris.

[0]
https://lists.mindrot.org/pipermail/openssh-unix-dev/2014-October/033056.html

-- 
You are receiving this mail because:
You are watching the assignee of the bug.

https://bugzilla.mindrot.org/show_bug.cgi?id=2302

Damien Miller <djm at mindrot.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |djm at mindrot.org
         Resolution|---                         |WONTFIX
             Status|NEW                         |RESOLVED

--- Comment #1 from Damien Miller <djm at mindrot.org> ---
It isn't falling back to a deselected KEX method, it's using a fallback
DH group that is completely compliant with the DHGEX method.

IMO the use of the fallback group is preferable to simply failing.

-- 
You are receiving this mail because:
You are watching someone on the CC list of the bug.
You are watching the assignee of the bug.

https://bugzilla.mindrot.org/show_bug.cgi?id=2302

Christoph Anton Mitterer <calestyo at scientia.net> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         Resolution|WONTFIX                     |---
             Status|RESOLVED                    |REOPENED

--- Comment #2 from Christoph Anton Mitterer <calestyo at scientia.net>
---
Hi Damien.

Reopening this for now because (see below):


(In reply to Damien Miller from comment #1)
> It isn't falling back to a deselected KEX method, it's using a
> fallback DH group that is completely compliant with the DHGEX method.
Okay,.. I see,... you're right.
Just checked that and with the server only offering
diffie-hellman-group-exchange-sha256 and /etc/ssh/moduli being empty, a
client can't connect with diffie-hellman-group1-sha1 or
diffie-hellman-group14-sha1, but can connect with an implicit 2048 bit
group with diffie-hellman-group-exchange-sha256.

But this is just something OpenSSH specific, right? Nothing which would
come from the RFC.

> IMO the use of the fallback group is preferable to simply failing.
Why?...


- This "failing" isn't much different from when the admin would
simply
disable all KexMethods... if he empties his /etc/moduli file, he
basically intentionally disables DH-GEX

Apart from that, only OpenSSH-to-OpenSSH would benefit from this, since
AFAICS, there is not standardised fallback group in DH-GEX.

Further, to get the idea behind such a fallback working (i.e.
compatibility and connections-always working) it means that OpenSSH
must keep that group basically forever (to allow interoperability)...
which OTOH prevents replacing "ageing" groups when their size is no
longer considered enough for security.

=> so I still think, not falling back would be better, since this seems
to be the logic effect one would expect from emptying /etc/ssh/moduli


But if you really insist on keeping this behaviour, could you then
please to the following:


- It makes it at least ambiguous in how things work since this
behaviour is not documented (i.e. people may think empty moduli file
means no group can be found/used for DH_GEX and therefore disables it.
=> so could this information be added to moduli(5) manpage?

- Replace the 2048b group that is used by something stronger? Looking
at the ECRYPT II recommendations... 2048 is not really enough for
longer terms.

-- 
You are receiving this mail because:
You are watching the assignee of the bug.
You are watching someone on the CC list of the bug.

https://bugzilla.mindrot.org/show_bug.cgi?id=2302

Christoph Anton Mitterer <calestyo at scientia.net> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
            Summary|ssh (and sshd) should not   |with DH-GEX, ssh (and sshd)
                   |fall back to deselected KEX |should not fall back to
                   |algos                       |unconfigured DH groups or
                   |                            |at least document this
                   |                            |behaviour and use a
                   |                            |stronger group

-- 
You are receiving this mail because:
You are watching someone on the CC list of the bug.
You are watching the assignee of the bug.

https://bugzilla.mindrot.org/show_bug.cgi?id=2302

Darren Tucker <dtucker at zip.com.au> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Assignee|unassigned-bugs at mindrot.org |dtucker at zip.com.au
                 CC|                            |dtucker at zip.com.au
   Attachment #2630|                            |ok?(djm at mindrot.org)
              Flags|                            |

--- Comment #3 from Darren Tucker <dtucker at zip.com.au> ---
Created attachment 2630
  --> https://bugzilla.mindrot.org/attachment.cgi?id=2630&action=edit
Make the DH-GEX fallback group 4k bit.

This makes the fallback group a new 4kbit group as long as the client
accepts groups at least that big (which is a SHOULD in RFC4419),
otherwise it continues to use group14.

I didn't go bigger than 4kbit because I know some implementations have
problems coping with them.

-- 
You are receiving this mail because:
You are watching the assignee of the bug.
You are watching someone on the CC list of the bug.

https://bugzilla.mindrot.org/show_bug.cgi?id=2302

--- Comment #4 from Damien Miller <djm at mindrot.org> ---
Comment on attachment 2630
  --> https://bugzilla.mindrot.org/attachment.cgi?id=2630
Make the DH-GEX fallback group 4k bit.

Where did this group come from? IMO it would be best to use one of the
standard groups if we're picking another fixed one - logjam attacks
aren't remotely plausible at this length, and doing so avoids any
questions over the group's provenance.

You could use the RFC3526 (ISAKMP) 4096-bit group:
https://tools.ietf.org/html/rfc3526#page-5

-- 
You are receiving this mail because:
You are watching someone on the CC list of the bug.
You are watching the assignee of the bug.

https://bugzilla.mindrot.org/show_bug.cgi?id=2302

--- Comment #5 from Darren Tucker <dtucker at zip.com.au> ---
(In reply to Damien Miller from comment #4)
> Comment on attachment 2630 [details]
> Make the DH-GEX fallback group 4k bit.
> 
> Where did this group come from?
I generated it.  I pulled it off the file being prepared for the next
moduli update.
> IMO it would be best to use one of
> the standard groups if we're picking another fixed one - logjam
> attacks aren't remotely plausible at this length, and doing so
> avoids any questions over the group's provenance.
Presumably someone said something similar about group1 and group14 at
one point?
> You could use the RFC3526 (ISAKMP) 4096-bit group:
> https://tools.ietf.org/html/rfc3526#page-5
Isn't the whole point of the LogJam style attacks is that up-front
precomputation against a fixed group used in many protocols pays
dividends across all of them?  In this case we need a group, but we
don't need that particular group.

-- 
You are receiving this mail because:
You are watching the assignee of the bug.
You are watching someone on the CC list of the bug.

Hi Folks,

The generator value of 5 does not lead to a q-ordered subgroup which is
needed to pass tests in

http://csrc.nist.gov/publications/nistpubs/800-56A/SP800-56A_Revision1_Mar08-2007.pdf

  1. Verify that 2 <= y <= p-2

  2. Verify that y^q = 1 (mod p)

It appears that choosing a generator values of 2, 3, 7, 11, or 13
would all work as generator values.

I do understand that RFC 4419 wants you to chose a g = 2 value only when
p (mod 24) == 11, but that is not always a good selection.

With the p value given, and q created with (p-1)/2, running

BN_is_prime_fasttest(p, 0, NULL, ctx, NULL, 0) shows p is prime
q = BN_dup(dhg.p)
BN_sub_word(q, 1)
BN_rshift1(q, q)
BN_is_prime_fasttest(q, 0, NULL, ctx, NULL, 0) shows q is prime
BN_mod_word(p, 24) == 23
BN_mod_word(p, 10) == 3		# RFC 4419 says g == 5 when p (mod 10) = 3
BN_mod_word(p, 12) == 11

If I use the values below, then NIST SP 800-56A Revision 1 of March 2007
tests work on all values of y that I tested. If I use a generator g = 5,
then I was getting failures.

static char *gen = "2";
static char *p 	    "DDE41D70" "21F9DF82"
"40D0BD8E" "14CE1E37" "4A4FFDD0"
	    "73767E84" "C8C347B6" "F8327312"
"77F9D333" "B8BC7CD9"
	    "6ED164DF" "5C6F26E4" "6E4BAF0A"
"A7C87B26" "CE3E1104"
	    "2C1BDDF7" "6095E50D" "7772E5DC"
"0C48EBA0" "E41EC92E"
	    "AFA655DA" "1B6C614E" "1F0F9AD8"
"15BD7505" "AA9B8A26"
	    "5D13956B" "5A26141E" "E812404D"
"E13B821C" "9B7BCA99"
	    "82B8CF7D" "862F8E8A" "373FEFEE"
"4AE46EC2" "122519A2"
	    "AD896ED1" "8CAECEF3" "14D1B98C"
"83358B6E" "9D2F3BC5"
	    "8C1688F1" "62E3CF1F" "F58E57E7"
"B9E14BB3" "7C9C9E96"
	    "92E57C42" "937141C2" "26E84C35"
"B42DED90" "55A7F366"
	    "A61C3CB4" "899B4992" "78ED4C72"
"9CC1DE54" "827E8822"
	    "90F9FC13" "F7F1488F" "897698EA"
"62A99468" "D6F3ED05"
	    "61816C39" "B8279154" "FC7A8E45"
"3CCC4EB1" "ABC777A3"
	    "97B694E1" "B9866C24" "95489F94"
"721A3351" "B252D05F"
	    "E6C78579" "29B34C19" "A8EB42AB"
"ED88FA37" "0DABCA83"
	    "A245DC35" "CFB39982" "4D127507"
"AD540054" "C647F61C"
	    "6BD11CAF" "C3FE5277" "A1014DF6"
"B538BC8B" "FE009315"
	    "BCD60E02" "0DAB840B" "8A4219EB"
"A4E34968" "0BC7CA3A"
	    "9BC36164" "A3D36E32" "5C530B17"
"8747814F" "57589912"
	    "6B307EB6" "3F910DDE" "0F09E505"
"6B2F9F7E" "230A42C1"
	    "1DDD34A9" "B23A6409" "0C2FF9C7"
"F3DD696E" "6828613E"
	    "74A64CFC" "4046ECFA" "997BE849"
"81430D8A" "7F8AEC63"
	    "001E50AF" "9F556567" "A0065A9A"
"013A66A2" "737CEEE4"
	    "68D6A150" "02358AC6" "48D862B0"
"618E6DD6" "A98BBBE9"
	    "E68174D9" "C9FE4568" "BB2D1208"
"3CF6892B" "6B8D5830"
	    "7944955A" "987F3791" "775049BF";

There is probaby a better way to calculate the generator g value using
FCC math, but I am pretty sure that the values you are putting into
https://bugzilla.mindrot.org/attachment.cgi?id=2630 are not going to
be useful if anyone needs to pass NIT SP 800-56A with those values.

Thanks for your time!

	-- Mark

https://bugzilla.mindrot.org/show_bug.cgi?id=2302

--- Comment #6 from Damien Miller <djm at mindrot.org> ---
(In reply to Darren Tucker from comment #5)
> (In reply to Damien Miller from comment #4)
> > Comment on attachment 2630 [details]
> > Make the DH-GEX fallback group 4k bit.
> > 
> > Where did this group come from?
> 
> I generated it.  I pulled it off the file being prepared for the
> next moduli update.
> 
> > IMO it would be best to use one of
> > the standard groups if we're picking another fixed one - logjam
> > attacks aren't remotely plausible at this length, and doing so
> > avoids any questions over the group's provenance.
> 
> Presumably someone said something similar about group1 and group14
> at one point?
Attacks on group 1 are barely plausible now (taking over 45M core years
for the precomputation), group14 seems well beyond reach. Check the
table on pg.8 of the logjam paper.

-- 
You are receiving this mail because:
You are watching the assignee of the bug.
You are watching someone on the CC list of the bug.

https://bugzilla.mindrot.org/show_bug.cgi?id=2302

Darren Tucker <dtucker at zip.com.au> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Attachment #2630|ok?(djm at mindrot.org)        |
              Flags|                            |
   Attachment #2630|0                           |1
        is obsolete|                            |
   Attachment #2631|                            |ok?(djm at mindrot.org)
              Flags|                            |

--- Comment #7 from Darren Tucker <dtucker at zip.com.au> ---
Created attachment 2631
  --> https://bugzilla.mindrot.org/attachment.cgi?id=2631&action=edit
Make the DH-GEX fallback group 4k bit from RFC3526

OK then.

-- 
You are receiving this mail because:
You are watching the assignee of the bug.
You are watching someone on the CC list of the bug.

https://bugzilla.mindrot.org/show_bug.cgi?id=2302

Darren Tucker <dtucker at zip.com.au> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Attachment #2631|0                           |1
        is obsolete|                            |
   Attachment #2631|ok?(djm at mindrot.org)        |
              Flags|                            |
   Attachment #2632|                            |ok?(djm at mindrot.org)
              Flags|                            |

--- Comment #8 from Darren Tucker <dtucker at zip.com.au> ---
Created attachment 2632
  --> https://bugzilla.mindrot.org/attachment.cgi?id=2632&action=edit
Make the DH-GEX fallback group 4k bit really from RFC3526

Damien points out a cut-and-paste error in the previous diff and that I
should not send out diffs before rushing off to things (ok, the latter
may be editorializing on my part).

-- 
You are receiving this mail because:
You are watching the assignee of the bug.
You are watching someone on the CC list of the bug.

https://bugzilla.mindrot.org/show_bug.cgi?id=2302

Damien Miller <djm at mindrot.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Attachment #2632|ok?(djm at mindrot.org)        |ok+
              Flags|                            |

-- 
You are receiving this mail because:
You are watching someone on the CC list of the bug.
You are watching the assignee of the bug.

https://bugzilla.mindrot.org/show_bug.cgi?id=2302

Darren Tucker <dtucker at zip.com.au> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|REOPENED                    |RESOLVED
             Blocks|                            |2360
         Resolution|---                         |FIXED

--- Comment #9 from Darren Tucker <dtucker at zip.com.au> ---
Patch applied and will be in the 6.9 release.  Thanks!

-- 
You are receiving this mail because:
You are watching someone on the CC list of the bug.
You are watching the assignee of the bug.

https://bugzilla.mindrot.org/show_bug.cgi?id=2302

--- Comment #10 from Christoph Anton Mitterer <calestyo at scientia.net>
---
Hey.

Let me try to catch up on this on as well :-)


(In reply to Darren Tucker from comment #3)
> Created attachment 2630 [details]
> Make the DH-GEX fallback group 4k bit.
I think that's a big step forward already.
AFAIU, the old fallback group is then removed?
> This makes the fallback group a new 4kbit group as long as the
> client accepts groups at least that big (which is a SHOULD in
> RFC4419), otherwise it continues to use group14.
Hmm that's not so good, OTOH.
I mean it's nice from the backward-compatibility PoV, but not so great
from the security PoV.

Even though an attacker cannot (AFAIU??) for a connection to downgrade
to the weaker groups, it still doesn't give the server admin a good way
to "block out" weak clients.
Sure, the client can always do what he likes (could be secure and still
publish everything on pastebin.com), but I think we should rather
strive to harden all possible places than focus on users who don't do
their homework and stick with years old clients.
It's basically the same why it's good and necessary that you guys
remove sshv1.

So even if this is much better now with the 4Ki group, I point to my
arguments in comment #2, especially as even the 4Ki group just shifts
the problem "a bit" into the future.


Last but not least, could we have:
>- It makes it at least ambiguous in how things work since this
>  behaviour is not documented (i.e. people may think empty moduli file 
>  means no group can be found/used for DH_GEX and therefore disables
>  it.
>  => so could this information be added to moduli(5) manpage?
?

-- 
You are receiving this mail because:
You are watching someone on the CC list of the bug.
You are watching the assignee of the bug.

https://bugzilla.mindrot.org/show_bug.cgi?id=2302

Christoph Anton Mitterer <calestyo at scientia.net> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         Resolution|FIXED                       |---
             Status|RESOLVED                    |REOPENED

--- Comment #11 from Christoph Anton Mitterer <calestyo at scientia.net>
---
I've written a small patch for the later, and therefore reopened this
bug for now.

-- 
You are receiving this mail because:
You are watching the assignee of the bug.
You are watching someone on the CC list of the bug.

https://bugzilla.mindrot.org/show_bug.cgi?id=2302

--- Comment #12 from Christoph Anton Mitterer <calestyo at scientia.net>
---
Created attachment 2640
  --> https://bugzilla.mindrot.org/attachment.cgi?id=2640&action=edit
0001-document-the-group-fallback-behaviour-in-DH-GEX.patch

-- 
You are receiving this mail because:
You are watching the assignee of the bug.
You are watching someone on the CC list of the bug.

https://bugzilla.mindrot.org/show_bug.cgi?id=2302

--- Comment #13 from Darren Tucker <dtucker at zip.com.au> ---
(In reply to Christoph Anton Mitterer from comment #10)
[...]
> Even though an attacker cannot (AFAIU??) for a connection to
> downgrade to the weaker groups,
The server's DH-GEX exchange hash includes the DH group sizes it
received from the client.  If these are modified in transit the
exchange hash will not match.
> it still doesn't give the server
> admin a good way to "block out" weak clients.
Do any such clients actually exist?  RFC4419 says DH-GEX
implementations SHOULD have a max group size of 8k.

-- 
You are receiving this mail because:
You are watching the assignee of the bug.
You are watching someone on the CC list of the bug.

On 2015-06-02 5:31 AM, bugzilla-daemon at mindrot.org
wrote:
> https://bugzilla.mindrot.org/show_bug.cgi?id=2302
>
> --- Comment #13 from Darren Tucker<dtucker at zip.com.au>  ---
> (In reply to Christoph Anton Mitterer from comment #10)
> [...]
>> Even though an attacker cannot (AFAIU??) for a connection to
>> downgrade to the weaker groups,
> The server's DH-GEX exchange hash includes the DH group sizes it
> received from the client.  If these are modified in transit the
> exchange hash will not match.
>
>> it still doesn't give the server
>> admin a good way to "block out" weak clients.
> Do any such clients actually exist?  RFC4419 says DH-GEX
> implementations SHOULD have a max group size of 8k.
>
Yes I expect. I have a ssh client from 2002 era that has worked very 
well for me (from ssh.com before they renamed it tectia) - and I would 
buy it again today - but they only to B2B these days.

Putty is functional, but I really prefer the 'tectia'-like UI.

I expect I will have no choice - other than replace it - as servers get 
tighter about key exchange protocols (mine still needs the (please dont 
hit me !) sha1 exchanges.

So, yes - they exist because until openssh-6.7 they were all supported 
by default - so again thank you (openbsd/openssh devs) for opening my 
eyes - and giving me time to adjust!

https://bugzilla.mindrot.org/show_bug.cgi?id=2302

Damien Miller <djm at mindrot.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Blocks|                            |2443

--- Comment #14 from Damien Miller <djm at mindrot.org> ---
Move unfinished bugs from 6.9 (how did I miss these?) to 7.1

-- 
You are receiving this mail because:
You are watching someone on the CC list of the bug.
You are watching the assignee of the bug.

https://bugzilla.mindrot.org/show_bug.cgi?id=2302

Darren Tucker <dtucker at zip.com.au> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Blocks|                            |2451


Referenced Bugs:

https://bugzilla.mindrot.org/show_bug.cgi?id=2451
[Bug 2451] Bugs intended to be fixed in 7.2
-- 
You are receiving this mail because:
You are watching the assignee of the bug.
You are watching someone on the CC list of the bug.

https://bugzilla.mindrot.org/show_bug.cgi?id=2302

Darren Tucker <dtucker at zip.com.au> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Blocks|2443                        |


Referenced Bugs:

https://bugzilla.mindrot.org/show_bug.cgi?id=2443
[Bug 2443] Bugs intended to be fixed for OpenSSH 7.1
-- 
You are receiving this mail because:
You are watching the assignee of the bug.
You are watching someone on the CC list of the bug.

https://bugzilla.mindrot.org/show_bug.cgi?id=2302

Damien Miller <djm at mindrot.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|REOPENED                    |RESOLVED
         Resolution|---                         |FIXED

--- Comment #15 from Damien Miller <djm at mindrot.org> ---
I've added a note to sshd(8) about fallback to internal groups.

-- 
You are receiving this mail because:
You are watching someone on the CC list of the bug.
You are watching the assignee of the bug.

https://bugzilla.mindrot.org/show_bug.cgi?id=2302

Damien Miller <djm at mindrot.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|RESOLVED                    |CLOSED

--- Comment #16 from Damien Miller <djm at mindrot.org> ---
Close all resolved bugs after 7.3p1 release

-- 
You are receiving this mail because:
You are watching someone on the CC list of the bug.
You are watching the assignee of the bug.