Re: OpenSSH bug in decoding EXT_INFO extension values

Damien Miller <djm@mindrot.org> Thu, 15 June 2017 17:19 UTC

Return-Path: <bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org>
X-Original-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com
Delivered-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DA53C126DFB for <ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com>; Thu, 15 Jun 2017 10:19:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.201
X-Spam-Level:
X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kL-SH1UB49nF for <ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com>; Thu, 15 Jun 2017 10:19:57 -0700 (PDT)
Received: from mail.netbsd.org (mail.NetBSD.org [IPv6:2001:470:a085:999::25]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 470511293EB for <secsh-tyoxbijeg7-archive@lists.ietf.org>; Thu, 15 Jun 2017 10:19:57 -0700 (PDT)
Received: by mail.netbsd.org (Postfix, from userid 605) id EC2A68559B; Thu, 15 Jun 2017 17:19:55 +0000 (UTC)
Delivered-To: ietf-ssh@netbsd.org
Received: by mail.netbsd.org (Postfix, from userid 1347) id 9C90785594; Thu, 15 Jun 2017 17:19:55 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1]) by mail.netbsd.org (Postfix) with ESMTP id BC04E84DE8 for <ietf-ssh@netbsd.org>; Tue, 13 Jun 2017 12:17:15 +0000 (UTC)
X-Virus-Scanned: amavisd-new at netbsd.org
Received: from mail.netbsd.org ([IPv6:::1]) by localhost (mail.netbsd.org [IPv6:::1]) (amavisd-new, port 10025) with ESMTP id GLJ9cadH-dZA for <ietf-ssh@netbsd.org>; Tue, 13 Jun 2017 12:17:15 +0000 (UTC)
Received: from newmailhub.uq.edu.au (mailhub2.soe.uq.edu.au [130.102.132.209]) by mail.netbsd.org (Postfix) with ESMTP id A376484C6C for <ietf-ssh@netbsd.org>; Tue, 13 Jun 2017 12:17:11 +0000 (UTC)
Received: from smtp1.soe.uq.edu.au (smtp1.soe.uq.edu.au [10.138.113.40]) by newmailhub.uq.edu.au (8.14.5/8.14.5) with ESMTP id v5DBBj1I002594; Tue, 13 Jun 2017 21:11:45 +1000
Received: from mailhub.eait.uq.edu.au (holly.eait.uq.edu.au [130.102.79.58]) by smtp1.soe.uq.edu.au (8.14.5/8.14.5) with ESMTP id v5DBBjur044232 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 13 Jun 2017 21:11:45 +1000
Received: from natsu.mindrot.org (natsu.mindrot.org [130.102.96.2]) by mailhub.eait.uq.edu.au (8.15.1/8.15.1) with ESMTPS id v5DBBiYf003068 (version=TLSv1.2 cipher=DHE-RSA-CHACHA20-POLY1305 bits=256 verify=NO); Tue, 13 Jun 2017 21:11:45 +1000 (AEST)
Received: by natsu.mindrot.org (Postfix, from userid 1000) id 78A07A4F38; Tue, 13 Jun 2017 21:11:44 +1000 (AEST)
Received: from localhost (localhost [127.0.0.1]) by natsu.mindrot.org (Postfix) with ESMTP id 72AEEA4F37; Tue, 13 Jun 2017 21:11:44 +1000 (AEST)
Date: Tue, 13 Jun 2017 21:11:44 +1000 (AEST)
From: Damien Miller <djm@mindrot.org>
To: "denis bider (Bitvise)" <ietf-ssh3@denisbider.com>
cc: ietf-ssh@netbsd.org, Markus Friedl <mfriedl@gmail.com>
Subject: Re: OpenSSH bug in decoding EXT_INFO extension values
In-Reply-To: <FC64DEB4AC654FDFA7150BA5D0351CF8@Khan>
Message-ID: <alpine.BSO.2.20.1706132110520.76321@natsu.mindrot.org>
References: <FC64DEB4AC654FDFA7150BA5D0351CF8@Khan>
User-Agent: Alpine 2.20 (BSO 67 2015-01-07)
MIME-Version: 1.0
Content-Type: multipart/mixed; BOUNDARY="0-1608668139-1497352304=:76321"
X-Scanned-By: MIMEDefang 2.73 on UQ Mailhub
X-Scanned-By: MIMEDefang 2.75 on 130.102.79.58
X-UQ-FilterTime: 1497352306
Sender: ietf-ssh-owner@NetBSD.org
List-Id: ietf-ssh.NetBSD.org
Precedence: list
List-Unsubscribe: <mailto:majordomo@NetBSD.org?subject=Unsubscribe%20ietf-ssh&body=unsubscribe%20ietf-ssh>

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