Re: OpenSSH bug in decoding EXT_INFO extension values

"denis bider \(Bitvise\)" <> Thu, 15 June 2017 17:22 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 95BA5129329 for <>; Thu, 15 Jun 2017 10:22:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.089
X-Spam-Status: No, score=-4.089 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, T_DKIM_INVALID=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=fail (2048-bit key) reason="fail (body has been altered)"
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id yJSWrbusZuvy for <>; Thu, 15 Jun 2017 10:22:10 -0700 (PDT)
Received: from ( [IPv6:2001:470:a085:999::25]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id E0088126D73 for <>; Thu, 15 Jun 2017 10:22:09 -0700 (PDT)
Received: by (Postfix, from userid 605) id E7B058559B; Thu, 15 Jun 2017 17:22:08 +0000 (UTC)
Received: by (Postfix, from userid 1347) id 94AE385594; Thu, 15 Jun 2017 17:22:08 +0000 (UTC)
Received: from localhost (localhost []) by (Postfix) with ESMTP id 341F084DB5 for <>; Wed, 14 Jun 2017 09:44:29 +0000 (UTC)
X-Virus-Scanned: amavisd-new at
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([IPv6:::1]) by localhost ( [IPv6:::1]) (amavisd-new, port 10025) with ESMTP id xTCBO6Pcni9A for <>; Wed, 14 Jun 2017 09:44:28 +0000 (UTC)
Received: from ( []) (using TLSv1.1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id EA11084CDA for <>; Wed, 14 Jun 2017 09:44:27 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;; s=mail; h=from:subject:date:message-id:to:cc:mime-version:content-type:in-reply-to: references; bh=O5L8fCH10+BsmIrfKqFmKEippN6dyRbEOdqgITVieME=; b=TKAtYUiAAyKS8rJAagAhmiYevD+tW4YxjJRHtvEhn0qTRzjzPaeKH5/mxpxJVZhy/lqCeUblyBSmz BcX9+m/Ujl05+alAg+urcG07xR0L7a+EMbyx4POKCSflucvXkhWuCGqJYvX+Iz27V7ZTEOVsLjTS3l Xtx+pSMpCokHw+CKEWw+77mxdaVzPPX4t2gPhUTNyqHaFz8sVwyScHjBcRbVJvXvmxFkMYLxFVdcy1 mNzAa6+SBR4DAbyfNub6MQk2FcPnb6+qqhzvWM1gfDIjR2RMMBrPPOPFQ2RhWRYWGWYa/Q8XMBXmgI hw8gxx5xmdSvwVfWmThZx8CXvVV0mnw==
X-Footer: ZGVuaXNiaWRlci5jb20=
Received: from localhost ([]) by with ESMTPSA (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256 bits)); Wed, 14 Jun 2017 10:44:10 +0100
Message-ID: <76D46D670C0D4EED9447537DB7C131E3@Khan>
From: "denis bider \(Bitvise\)" <>
To: "Damien Miller" <>
Cc: <>, "Markus Friedl" <>
References: <FC64DEB4AC654FDFA7150BA5D0351CF8@Khan> <>
In-Reply-To: <>
Subject: Re: OpenSSH bug in decoding EXT_INFO extension values
Date: Wed, 14 Jun 2017 03:43:42 -0600
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_063B_01D2E4C0.6AE85330"
X-Priority: 3
X-MSMail-Priority: Normal
Importance: Normal
X-Mailer: Microsoft Windows Live Mail 16.4.3528.331
X-MimeOLE: Produced By Microsoft MimeOLE V16.4.3528.331
Precedence: list
List-Unsubscribe: <>

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.


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

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.
> 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) {
> }
> 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