From patchwork Tue May 9 14:42:29 2017 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Amit Pundir X-Patchwork-Id: 98918 Delivered-To: patch@linaro.org Received: by 10.140.96.100 with SMTP id j91csp1857384qge; Tue, 9 May 2017 07:43:08 -0700 (PDT) X-Received: by 10.99.145.195 with SMTP id l186mr503864pge.123.1494340988660; Tue, 09 May 2017 07:43:08 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1494340988; cv=none; d=google.com; s=arc-20160816; b=lw3IhYPO88bZThGDgXv7srXH0Zug/jgWhoCa8mz0iPeljsljwwxxVuRgFG+HJxAhDu 1zedollHQzl2sIibvabqe1hXDc7urts2YPHKLESE772mXdOnGhoWMJUK1oWGQrOGQYU2 6OUS/vO59Yz4/4sLUWuKfEtPE+m3pXU6uewm4YqortmmERXBFqzANO27yilYQdoBDlp4 p79D3qV52VbjBLS90yiBJgi19azV5G49+FdAw0HyePPhfaVa9RbtYqDAbWpVlWaVgWCq tlis/pGiu//zPRk128XqB8hinNiYLRJpwyNmtLTRo55ZWh5NFlZDp9vgALgGfs0N+fJH qRzA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:references:in-reply-to:message-id:date :subject:cc:to:from:dkim-signature:arc-authentication-results; bh=nMiSX2gLbPL9P610RbCwqPUIMthkfp5Gr//oxq6zNRw=; b=EO+Ee+QjKXesF1KlBXZG46DalqF2au/NTKhGb0sU5Z2z6noDFlIgyPCPVfd318Tpgg LPxSiwQK4feVrw7KetIDKjb1S/dTkdkzYhFnCB2F/Fc2VsVrzX1fWcnrUi6iwLHCorIk uDcVwelRNDuJrH8HKhr2TEFKQwrCXt++2KQQ+9MmXIgdl7yzjYC5oZYWkA6C1JH4zSBb eKnCzrSEOT5c56UFJYTzb/iAnwB/arGkRpaa28v+5LstDZTbs6i1U3OnvGLNqFl/poZS Znwg1AlRUEYkNCvwj/QavC+fHQ6E6tTbUQx8GOTe/wsJ1COBKtYGRHi4YvCkoS8gbh3Y FCxA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linaro.org; spf=pass (google.com: best guess record for domain of stable-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=stable-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linaro.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id w34si113540pla.121.2017.05.09.07.43.08; Tue, 09 May 2017 07:43:08 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of stable-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=pass header.i=@linaro.org; spf=pass (google.com: best guess record for domain of stable-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=stable-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linaro.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753557AbdEIOnH (ORCPT + 6 others); Tue, 9 May 2017 10:43:07 -0400 Received: from mail-pg0-f46.google.com ([74.125.83.46]:32940 "EHLO mail-pg0-f46.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752426AbdEIOnG (ORCPT ); Tue, 9 May 2017 10:43:06 -0400 Received: by mail-pg0-f46.google.com with SMTP id u187so782161pgb.0 for ; Tue, 09 May 2017 07:43:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=from:to:cc:subject:date:message-id:in-reply-to:references; bh=nMiSX2gLbPL9P610RbCwqPUIMthkfp5Gr//oxq6zNRw=; b=j/6/6nlvOtOTXdt0ZsYOF811ejov+gQBE3LpphZpNNX0yQtAY0feUkIhFtse6TwwO2 wsG3VcElkCON+mqBxo62EHJvfNr8ie0XxMceGCTq6MKUvd4SG7yvW6LuXeWj26qd6aHx zVsYo/cmW09T5Wi9GCf6+a0cZX+QfSc6QqZPc= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:date:message-id:in-reply-to :references; bh=nMiSX2gLbPL9P610RbCwqPUIMthkfp5Gr//oxq6zNRw=; b=c+lgHipFq2mIFMVZ4Zx6vEFKk6/FIG41If4GPm6bos5cAPipvqMNYdzwnHBDmGGgab LtMWk1VTzOo7xteVb2Mj8VffqkbANDuN4OydXpGe7RF3nZ98GrcyV+7n73cEzXoOinsL oiN8emM0at/ajUE0xBiPNOF0qRYiB9VrxQZXUx5+1+4apgbqQTn2P0xGfN+jfj+r5W4W nH6jJpV2D3wjaLOx9gZHBqBa35iKmhSS+iQLLWYfky/U7kummwrgRkVZoDmlieH+jVX6 aCNq+gZ7T5a/+VC2eYFElpuLkc+1ekKB8Ju4tcDosLJ57VJ3NfdF0bWr5KOEhbaKGBhC OJfA== X-Gm-Message-State: AODbwcDUXuqQ5ha8w4wTIKGs+aaeX5vhBLFdCvygQkoDD2kLLDu8iiUp kXLDFMJUO1EbOWZHeGAfqw== X-Received: by 10.84.198.164 with SMTP id p33mr641761pld.127.1494340985932; Tue, 09 May 2017 07:43:05 -0700 (PDT) Received: from localhost.localdomain ([106.51.135.126]) by smtp.gmail.com with ESMTPSA id 11sm341811pfj.59.2017.05.09.07.43.04 (version=TLS1_2 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Tue, 09 May 2017 07:43:05 -0700 (PDT) From: Amit Pundir To: Greg KH Cc: stable@vger.kernel.org, David Howells Subject: [PATCH for-3.18 05/24] ASN.1: Fix non-match detection failure on data overrun Date: Tue, 9 May 2017 20:12:29 +0530 Message-Id: <1494340968-17152-6-git-send-email-amit.pundir@linaro.org> X-Mailer: git-send-email 2.7.4 In-Reply-To: <1494340968-17152-1-git-send-email-amit.pundir@linaro.org> References: <1494340968-17152-1-git-send-email-amit.pundir@linaro.org> Sender: stable-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: stable@vger.kernel.org From: David Howells commit 0d62e9dd6da45bbf0f33a8617afc5fe774c8f45f upstream. If the ASN.1 decoder is asked to parse a sequence of objects, non-optional matches get skipped if there's no more data to be had rather than a data-overrun error being reported. This is due to the code segment that decides whether to skip optional matches (ie. matches that could get ignored because an element is marked OPTIONAL in the grammar) due to a lack of data also skips non-optional elements if the data pointer has reached the end of the buffer. This can be tested with the data decoder for the new RSA akcipher algorithm that takes three non-optional integers. Currently, it skips the last integer if there is insufficient data. Without the fix, #defining DEBUG in asn1_decoder.c will show something like: next_op: pc=0/13 dp=0/270 C=0 J=0 - match? 30 30 00 - TAG: 30 266 CONS next_op: pc=2/13 dp=4/270 C=1 J=0 - match? 02 02 00 - TAG: 02 257 - LEAF: 257 next_op: pc=5/13 dp=265/270 C=1 J=0 - match? 02 02 00 - TAG: 02 3 - LEAF: 3 next_op: pc=8/13 dp=270/270 C=1 J=0 next_op: pc=11/13 dp=270/270 C=1 J=0 - end cons t=4 dp=270 l=270/270 The next_op line for pc=8/13 should be followed by a match line. This is not exploitable for X.509 certificates by means of shortening the message and fixing up the ASN.1 CONS tags because: (1) The relevant records being built up are cleared before use. (2) If the message is shortened sufficiently to remove the public key, the ASN.1 parse of the RSA key will fail quickly due to a lack of data. (3) Extracted signature data is either turned into MPIs (which cope with a 0 length) or is simpler integers specifying algoritms and suchlike (which can validly be 0); and (4) The AKID and SKID extensions are optional and their removal is handled without risking passing a NULL to asymmetric_key_generate_id(). (5) If the certificate is truncated sufficiently to remove the subject, issuer or serialNumber then the ASN.1 decoder will fail with a 'Cons stack underflow' return. This is not exploitable for PKCS#7 messages by means of removal of elements from such a message from the tail end of a sequence: (1) Any shortened X.509 certs embedded in the PKCS#7 message are survivable as detailed above. (2) The message digest content isn't used if it shows a NULL pointer, similarly, the authattrs aren't used if that shows a NULL pointer. (3) A missing signature results in a NULL MPI - which the MPI routines deal with. (4) If data is NULL, it is expected that the message has detached content and that is handled appropriately. (5) If the serialNumber is excised, the unconditional action associated with it will pick up the containing SEQUENCE instead, so no NULL pointer will be seen here. If both the issuer and the serialNumber are excised, the ASN.1 decode will fail with an 'Unexpected tag' return. In either case, there's no way to get to asymmetric_key_generate_id() with a NULL pointer. (6) Other fields are decoded to simple integers. Shortening the message to omit an algorithm ID field will cause checks on this to fail early in the verification process. This can also be tested by snipping objects off of the end of the ASN.1 stream such that mandatory tags are removed - or even from the end of internal SEQUENCEs. If any mandatory tag is missing, the error EBADMSG *should* be produced. Without this patch ERANGE or ENOPKG might be produced or the parse may apparently succeed, perhaps with ENOKEY or EKEYREJECTED being produced later, depending on what gets snipped. Just snipping off the final BIT_STRING or OCTET_STRING from either sample should be a start since both are mandatory and neither will cause an EBADMSG without the patches Reported-by: Marcel Holtmann Signed-off-by: David Howells Tested-by: Marcel Holtmann Reviewed-by: David Woodhouse Signed-off-by: Amit Pundir --- lib/asn1_decoder.c | 5 ++--- 1 file changed, 2 insertions(+), 3 deletions(-) -- 2.7.4 diff --git a/lib/asn1_decoder.c b/lib/asn1_decoder.c index 1a000bb050f9..d60ce8a53650 100644 --- a/lib/asn1_decoder.c +++ b/lib/asn1_decoder.c @@ -208,9 +208,8 @@ next_op: unsigned char tmp; /* Skip conditional matches if possible */ - if ((op & ASN1_OP_MATCH__COND && - flags & FLAG_MATCHED) || - dp == datalen) { + if ((op & ASN1_OP_MATCH__COND && flags & FLAG_MATCHED) || + (op & ASN1_OP_MATCH__SKIP && dp == datalen)) { pc += asn1_op_lengths[op]; goto next_op; }