From patchwork Wed Oct 19 14:07:17 2022 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Nikolaus Voss X-Patchwork-Id: 5602 Return-Path: Delivered-To: ouuuleilei@gmail.com Received: by 2002:a5d:4ac7:0:0:0:0:0 with SMTP id y7csp367458wrs; Wed, 19 Oct 2022 07:47:10 -0700 (PDT) X-Google-Smtp-Source: AMsMyM4HaPsGue5FZRw/CoQiUaQ0QoVYZJeikSHNoSjrtSf2YAISk46EiyemBzboFKaF08YwCXnR X-Received: by 2002:a17:903:2448:b0:17f:8069:532a with SMTP id l8-20020a170903244800b0017f8069532amr8779875pls.95.1666190829943; Wed, 19 Oct 2022 07:47:09 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1666190829; cv=none; d=google.com; s=arc-20160816; b=SuqpIx71ABVQjLBNwnkP4tCkIFitlNHd6jsYU1RQN8XXJO6j15VQTrzIKvlf6DGeGF JY1+HgObs+SemtsRIUj/71SF5EdvD9cWBC8yuARgvQMPP9rbQj4FbaIHVBvLPIGdRgeX bwheMMP11pGhe0VbG/HO1OKSgXFwjJvgiQFeOA9MoLU+rXCsaK3X54j6p6mREeC+3Wh5 ZvtYYwp7yanzfw0qeGg+QzHciF+v3DM+LSt7PxS9+9BpYjZFpubFy57QavXLCs0LYgLu 9JQFyZWyTBjF8176vpHfoAjAoeUBLHBySCEd2zVz8jnnEzc00KLeokmbVz/FPohcYSGx e6Ww== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:message-id:subject:date:cc:to:from; bh=lLDDCyXRTJOWhxuUHqPL9ItsW64heuWj1Ec1Pqmbvas=; b=SIc6BXUKN17D6NM7EKqwdW+4IyoYt9PXNeBSoSwQ/0cTNBHVrQJTYBTVQPvKExkei6 j+jwZl5OnGap9x/fsxdjcMLvIpq6EjBhBsXzYgmGq9kr0UtqlaVxnYhrA5i9X/ZIFIZs dm7XeOxC9ZdBbXC0RrHU1+30qrlzlaiIcZDwsaY8DANE9iOAyTIt15UWL5k51lLzEoSc EYCawFAc9Ev1WBvPIWmzr89KI8B9+eC39ctbTdDjmDqQw+qhgJtJ6SfYR1exux/je+z7 sb+9UR4IbUU3H8nSrcWszkBuOsf2bWCbhDTg73qpSGH/EVbXLed/SCVrSOBBcmybUnoo bwug== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id b7-20020a17090a488700b0020d457c5083si76113pjh.147.2022.10.19.07.46.55; Wed, 19 Oct 2022 07:47:09 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230212AbiJSOh7 (ORCPT + 99 others); Wed, 19 Oct 2022 10:37:59 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:57202 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229922AbiJSOhk (ORCPT ); Wed, 19 Oct 2022 10:37:40 -0400 Received: from mail.steuer-voss.de (mail.steuer-voss.de [85.183.69.95]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 15D641D79BD; Wed, 19 Oct 2022 07:21:44 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at mail.steuer-voss.de Received: by mail.steuer-voss.de (Postfix, from userid 1000) id E605D1B3B; Wed, 19 Oct 2022 16:10:31 +0200 (CEST) From: Nikolaus Voss To: Mimi Zohar , David Howells , Jarkko Sakkinen , James Morris , "Serge E. Hallyn" , Yael Tzur , Cyril Hrubis , Petr Vorel Cc: linux-integrity@vger.kernel.org, keyrings@vger.kernel.org, linux-security-module@vger.kernel.org, linux-kernel@vger.kernel.org Date: Wed, 19 Oct 2022 16:07:17 +0200 Subject: [PATCH v5] KEYS: encrypted: fix key instantiation with user-provided data Message-Id: <20221019141031.E605D1B3B@mail.steuer-voss.de> X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,SPF_HELO_NONE, SPF_NONE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org X-getmail-retrieved-from-mailbox: =?utf-8?q?INBOX?= X-GMAIL-THRID: =?utf-8?q?1747127715607269110?= X-GMAIL-MSGID: =?utf-8?q?1747127715607269110?= Commit cd3bc044af48 ("KEYS: encrypted: Instantiate key with user-provided decrypted data") added key instantiation with user provided decrypted data. The user data is hex-ascii-encoded but was just memcpy'ed to the binary buffer. Fix this to use hex2bin instead. Old keys created from user provided decrypted data saved with "keyctl pipe" are still valid, however if the key is recreated from decrypted data the old key must be converted to the correct format. This can be done with a small shell script, e.g.: BROKENKEY=abcdefABCDEF1234567890aaaaaaaaaa NEWKEY=$(echo -ne $BROKENKEY | xxd -p -c32) keyctl add user masterkey "$(cat masterkey.bin)" @u keyctl add encrypted testkey "new user:masterkey 32 $NEWKEY" @u However, NEWKEY is still broken: If for BROKENKEY 32 bytes were specified, a brute force attacker knowing the key properties would only need to try at most 2^(16*8) keys, as if the key was only 16 bytes long. The security issue is a result of the combination of limiting the input range to hex-ascii and using memcpy() instead of hex2bin(). It could have been fixed either by allowing binary input or using hex2bin() (and doubling the ascii input key length). This patch implements the latter. The corresponding test for the Linux Test Project ltp has also been fixed (see link below). Fixes: cd3bc044af48 ("KEYS: encrypted: Instantiate key with user-provided decrypted data") Cc: stable Link: https://lore.kernel.org/ltp/20221006081709.92303897@mail.steuer-voss.de/ Reviewed-by: Mimi Zohar Signed-off-by: Nikolaus Voss --- Changes ======= v5: - explain security issue in commit message, add Reviewd-by v4: - change "Link:" address v3: - use generated random key in example, reformat commit message v2: - clarify commit message, add example to recover old/broken keys - improve example in Documentation/security/keys/trusted-encrypted.rst - add link to ltp patch Documentation/security/keys/trusted-encrypted.rst | 3 ++- security/keys/encrypted-keys/encrypted.c | 6 +++--- 2 files changed, 5 insertions(+), 4 deletions(-) diff --git a/Documentation/security/keys/trusted-encrypted.rst b/Documentation/security/keys/trusted-encrypted.rst index 0bfb4c339748..9bc9db8ec651 100644 --- a/Documentation/security/keys/trusted-encrypted.rst +++ b/Documentation/security/keys/trusted-encrypted.rst @@ -350,7 +350,8 @@ Load an encrypted key "evm" from saved blob:: Instantiate an encrypted key "evm" using user-provided decrypted data:: - $ keyctl add encrypted evm "new default user:kmk 32 `cat evm_decrypted_data.blob`" @u + $ evmkey=$(dd if=/dev/urandom bs=1 count=32 | xxd -c32 -p) + $ keyctl add encrypted evm "new default user:kmk 32 $evmkey" @u 794890253 $ keyctl print 794890253 diff --git a/security/keys/encrypted-keys/encrypted.c b/security/keys/encrypted-keys/encrypted.c index e05cfc2e49ae..1e313982af02 100644 --- a/security/keys/encrypted-keys/encrypted.c +++ b/security/keys/encrypted-keys/encrypted.c @@ -627,7 +627,7 @@ static struct encrypted_key_payload *encrypted_key_alloc(struct key *key, pr_err("encrypted key: instantiation of keys using provided decrypted data is disabled since CONFIG_USER_DECRYPTED_DATA is set to false\n"); return ERR_PTR(-EINVAL); } - if (strlen(decrypted_data) != decrypted_datalen) { + if (strlen(decrypted_data) != decrypted_datalen * 2) { pr_err("encrypted key: decrypted data provided does not match decrypted data length provided\n"); return ERR_PTR(-EINVAL); } @@ -791,8 +791,8 @@ static int encrypted_init(struct encrypted_key_payload *epayload, ret = encrypted_key_decrypt(epayload, format, hex_encoded_iv); } else if (decrypted_data) { get_random_bytes(epayload->iv, ivsize); - memcpy(epayload->decrypted_data, decrypted_data, - epayload->decrypted_datalen); + ret = hex2bin(epayload->decrypted_data, decrypted_data, + epayload->decrypted_datalen); } else { get_random_bytes(epayload->iv, ivsize); get_random_bytes(epayload->decrypted_data, epayload->decrypted_datalen);