Subject: OpenSSH bug in decoding EXT_INFO extension values

From: "denis bider \(Bitvise\)" <[email-masked]>
Date: Mon, 12 Jun 2017 21:53:07 -0600

Bad news, everyone.

Again - there’s a bug in OpenSSH that’s now widely deployed, and will 
require workarounds to coexist with.

OpenSSH implements EXT_INFO. Excellent. Very nice. I'm grateful. Thank you.

But it does so incorrectly.

Suppose that a server sends the "delay-compression" extension to an OpenSSH 
client.

The client disconnects, without attempting to authenticate, as soon as it 
sees the extension's encoding.

It disconnects due to this choice of function in kex_input_ext_info:

if ((r = sshpkt_get_cstring(ssh, &val, NULL)) != 0) {
    free(name);
    return r;
}

This is an incorrect function to use for the extension value, because it 
contains the following logic:

/* Allow a \0 only at the end of the string */
if (len > 0 &&
    (z = memchr(p , '\0', len)) != NULL && z < p + len - 1) {
    SSHBUF_DBG(("SSH_ERR_INVALID_FORMAT"));
    return SSH_ERR_INVALID_FORMAT;
}

THIS IS NOT CORRECT LOGIC TO USE WHEN PROCESSING AN UNKNOWN EXTENSION VALUE, 
OF UNKNOWN FORMAT, WHERE THERE'S NO GUARANTEE IT WON'T CONTAIN ZEROS!

The value for the “delay-compression” extension, in particular, contains 
zeros.

The whole extension is defined as follows:

string         "delay-compression"
string:
  name-list    compression_algorithms_client_to_server
  name-list    compression_algorithms_server_to_client

Obviously, the lengths of both name-lists will have zeros, which will appear 
right at the start of the value.

So we implement an extension mechanism - and once again, it cannot be used 
with OpenSSH, because it deploys a fundamentally botched implementation.

Remember - the reason this "delay-compression" extension exists IN THE FIRST 
PLACE is that OpenSSH botched its delayed compression; designing it with a 
built-in, unescapable race condition.

God dammit, guys. God dammit.

What should I do with this?

Not send "delay-compression" to OpenSSH versions up to 7.5?

Or not send it to ANY OpenSSH version?

denis

---

From: Damien Miller <[email-masked]>
Date: Tue, 13 Jun 2017 21:11:44 +1000 (AEST)

Yes, this is a bug in OpenSSH.

Yes, we'll fix it for 7.6.

Yes, your attitude and approach stinks.

On Mon, 12 Jun 2017, denis bider (Bitvise) wrote:

> Bad news, everyone.
> 
> Again - there’s a bug in OpenSSH that’s now widely deployed, and will require
> workarounds to coexist with.
> 
> The client disconnects, without attempting to authenticate, as soon as it sees
> the extension's encoding.
>

---

From: "denis bider \(Bitvise\)" <[email-masked]>
Date: Wed, 14 Jun 2017 03:43:42 -0600

I appreciate the acknowledgment. I will plan accordingly. Thank you!

My attitude does stink. I’m afraid this comes from frustration with your work over the past 17 years.

This will seem unfair to you because you value your work on the basis of what good it does.

Your work does a lot of good. It is a security-conscious project, with a quality of implementation that exceeds at least half of commercial implementations. It makes a difference in day to day lives for millions of users. It improves the overall security of the internet. Its open source nature is a valuable counterweight that helps keep in reign IP encroachment by commercial implementations.

I could be cynical, and say that “one gets what one pays for”. This would be partly true, in ways you might not be aware of. But it would also be fundamentally unfair, because the value of your work is much more than anyone pays.

I don’t know about your circumstance. I don’t know if you are adequately compensated for the work you do by some benevolent benefactor. It is possible that you are not, and if you’re not, I consider this a significant unfairness. If this is the case, it’s an unfairness you have chosen, but it’s unfair nevertheless.

All of this being said – although I can praise your project in all these respects, and I can consider it better than a number of commercial implementations;

and although the very fact that I can have this conversation with you is meaningful, and valuable; it is more than is possible in many cases, and I do not take it for granted;

all of these things being said...

I am another implementor who is not part of your project; and therefore does not have influence.

So when you do things in your project that are short-sighted; or are poorly planned; or do not consider the impact on others; in such cases, I am impacted.

And because I do not have control; my reaction is not “OK, so this looks like a mistake. Everyone makes mistakes. These guys are doing valuable work for free. The world should be thankful for their efforts.” My reaction instead is: “OMG, these open source developers again, and what passes their threshold for quality work.”

This is partly unfair, because as I’ve said, your work is actually better than 50% of commercial implementations. That is without counting those implementations that are actually ripping off from your work. :)

But I hold you to a higher standard, and that’s not despite your work being free, but because it is free, and therefore popular. I feel that with the market position you have, comes great responsibility.

And the reason I’m peeved is because I feel that the problem is not accidental, but systemic. If you participate in an open source project as long as you do, you’re not just giving the world a freebie. You are writing the code for a principle. If your aim is to serve a principle; and your software becomes overwhelmingly popular because people see and recognize your commitment; then you are also taking on responsibility.

And when you do that, I am then peeved if you simultaneously abrogate this responsibility, by developing, planning, and designing sloppily.

If you’re going to uphold a principle, then uphold a great principle, dammit. Do excellent work. Don’t be satisfied with adequate. :)

Again, I have no idea how this is experienced on your end. And yes – your code is still better than many.

And it’s better, and more responsible, and your development process is more responsive, than commercial companies have been in similar leading market positions.

denis

From: Damien Miller 
Sent: Tuesday, June 13, 2017 05:11
To: denis bider (Bitvise) 
Cc: [email-masked] ; Markus Friedl 
Subject: Re: OpenSSH bug in decoding EXT_INFO extension values

---

From: Mouse <[email-masked]>
Date: Thu, 15 Jun 2017 16:38:30 -0400 (EDT)

> My attitude does stink. I=E2=80=99m afraid this comes from frustration =
> with your work over the past 17 years.

> This will seem unfair to you [...]

Rarely have I seen more eloquently expressed the frustration and
dilemma of a user discovering a problem with a widely-deployed
open-source program.

And civilly, too, and with full acknowledgement and understanding of
the other side of the fence.

You, Sir, are an exemplar I wish I were better able to live up to.

/~\ The ASCII				  Mouse
\ / Ribbon Campaign
 X  Against HTML		[email-masked]
/ \ Email!	     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B

---

From: Markus Friedl <[email-masked]>
Date: Fri, 23 Jun 2017 14:41:56 +0200

2017-06-14 11:43 GMT+02:00 denis bider (Bitvise) <[email-masked]>:

> And when you do that, I am then peeved if you simultaneously abrogate this
> responsibility, by developing, planning, and designing sloppily.

Just try to make simpler protocol extensions, so I can keep seeing sloppy

-m

---

From: "denis bider \(Bitvise\)" <[email-masked]>
Date: Fri, 23 Jun 2017 07:18:25 -0600

Aye – I thought there’s nothing simpler than:

  string extension-name
  string extension-value <= can contain any value!

But... there we go. :)

It’s fascinating how much non-simplicity one discovers in things that seem simple. *sigh* You know what the most common misunderstanding of our users is?

They don’t know what’s a “client” and what’s a “server”.

From: Markus Friedl 
Sent: Friday, June 23, 2017 06:41
To: denis bider (Bitvise) 
Cc: Damien Miller ; [email-masked] 
Subject: Re: OpenSSH bug in decoding EXT_INFO extension values

-m