Received: by 10.223.185.116 with SMTP id b49csp4169122wrg; Mon, 26 Feb 2018 12:27:35 -0800 (PST) X-Google-Smtp-Source: AH8x2256ujNQcyrktCqcMvu5mRSKBGHzh3WfczRCMn1Aq81BojA6Jo0GdBrO0Uu35vYGZNPVrZiI X-Received: by 2002:a17:902:8487:: with SMTP id c7-v6mr11681726plo.7.1519676855865; Mon, 26 Feb 2018 12:27:35 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1519676855; cv=none; d=google.com; s=arc-20160816; b=c/e26ZHysV9Gc3NTq7ftC0/Zym+J8zP11A+ThCTNhnxTnMflQlGsjBhmh8MAgKpNbK 2fx2LBqI+XGKBx6A7Oe60/tP1EfTEkp9rQ/A3m/ZwXmbNFn0uJEJEDE7CxA50ayxWMO5 vHW2y7iFqHjZBgIovD0/r72IdPmrDj/0J6pKexmRK1lgLPBKnzNeT/D0Ole3YPlNea47 sEql5ayPUncRklHCDTiIQT6Pqwy9QhfU+38sCMEWJxZrIkQiVaVmEwZW8OpkVBdXRSWj 33QKlncZw/ep8tI80o2C1+Fj/XlETlsTfZnsDW6LjAg3lxAONZVs3cj/1sihjdiVfqDf IlXw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:mime-version:user-agent:references :in-reply-to:message-id:date:subject:cc:to:from :arc-authentication-results; bh=JcqhGjhFBfaV2iGptlbmuBR3jGUGK06L19gejat8cFY=; b=ZSzcYo0pis3amQPKz7KDfO0T5Hed4kzLkxP2R0h9gIkYG61YqmdzMAt+IJPFZkUDGe 1T4sMmBkM++ok67hMLFkJrKNPYDiM68ka+oHn7IDW3D8N/FDUjnnk1L6DXMS9+AOJj5e YUfjjEd4rYQQIqyFBaccZgNgOhbU9YwmGmASDcNZ41hXi2z7XkZbkhznsCWUZMSNPU9a eqzg0Uhebj2akuuUm5LHsni0TX6XKZsu0vG1rfdiSvJidIk6uKEBQ3AjXgqjcg7DXd1s /AOk9rJepRpvpfqqaaBFloGgfKR6dd4ZHR7yqRA38E640oFtSgscieuRtFnt2zz5pDhw yvJQ== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id w12si5951763pgr.211.2018.02.26.12.27.19; Mon, 26 Feb 2018 12:27:35 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753372AbeBZU0X (ORCPT + 99 others); Mon, 26 Feb 2018 15:26:23 -0500 Received: from mail.linuxfoundation.org ([140.211.169.12]:35676 "EHLO mail.linuxfoundation.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753350AbeBZU0R (ORCPT ); Mon, 26 Feb 2018 15:26:17 -0500 Received: from localhost (clnet-b04-243.ikbnet.co.at [83.175.124.243]) by mail.linuxfoundation.org (Postfix) with ESMTPSA id 5C9C8FE5; Mon, 26 Feb 2018 20:26:16 +0000 (UTC) From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Eric Biggers , David Howells Subject: [PATCH 4.15 13/64] PKCS#7: fix certificate chain verification Date: Mon, 26 Feb 2018 21:21:50 +0100 Message-Id: <20180226202154.014220555@linuxfoundation.org> X-Mailer: git-send-email 2.16.2 In-Reply-To: <20180226202153.453363333@linuxfoundation.org> References: <20180226202153.453363333@linuxfoundation.org> User-Agent: quilt/0.65 X-stable: review MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 4.15-stable review patch. If anyone has any objections, please let me know. ------------------ From: Eric Biggers commit 971b42c038dc83e3327872d294fe7131bab152fc upstream. When pkcs7_verify_sig_chain() is building the certificate chain for a SignerInfo using the certificates in the PKCS#7 message, it is passing the wrong arguments to public_key_verify_signature(). Consequently, when the next certificate is supposed to be used to verify the previous certificate, the next certificate is actually used to verify itself. An attacker can use this bug to create a bogus certificate chain that has no cryptographic relationship between the beginning and end. Fortunately I couldn't quite find a way to use this to bypass the overall signature verification, though it comes very close. Here's the reasoning: due to the bug, every certificate in the chain beyond the first actually has to be self-signed (where "self-signed" here refers to the actual key and signature; an attacker might still manipulate the certificate fields such that the self_signed flag doesn't actually get set, and thus the chain doesn't end immediately). But to pass trust validation (pkcs7_validate_trust()), either the SignerInfo or one of the certificates has to actually be signed by a trusted key. Since only self-signed certificates can be added to the chain, the only way for an attacker to introduce a trusted signature is to include a self-signed trusted certificate. But, when pkcs7_validate_trust_one() reaches that certificate, instead of trying to verify the signature on that certificate, it will actually look up the corresponding trusted key, which will succeed, and then try to verify the *previous* certificate, which will fail. Thus, disaster is narrowly averted (as far as I could tell). Fixes: 6c2dc5ae4ab7 ("X.509: Extract signature digest and make self-signed cert checks earlier") Cc: # v4.7+ Signed-off-by: Eric Biggers Signed-off-by: David Howells Signed-off-by: Greg Kroah-Hartman --- crypto/asymmetric_keys/pkcs7_verify.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- a/crypto/asymmetric_keys/pkcs7_verify.c +++ b/crypto/asymmetric_keys/pkcs7_verify.c @@ -270,7 +270,7 @@ static int pkcs7_verify_sig_chain(struct sinfo->index); return 0; } - ret = public_key_verify_signature(p->pub, p->sig); + ret = public_key_verify_signature(p->pub, x509->sig); if (ret < 0) return ret; x509->signer = p;