From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-15.8 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_PATCH,MAILING_LIST_MULTI, MENTIONS_GIT_HOSTING,NICE_REPLY_A,SPF_HELO_NONE,SPF_PASS,USER_AGENT_SANE_1 autolearn=unavailable autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 83AC0C47082 for ; Sat, 5 Jun 2021 11:05:50 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 5BFE961354 for ; Sat, 5 Jun 2021 11:05:50 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230099AbhFELHh (ORCPT ); Sat, 5 Jun 2021 07:07:37 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:34858 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229929AbhFELHf (ORCPT ); Sat, 5 Jun 2021 07:07:35 -0400 X-Greylist: delayed 470 seconds by postgrey-1.37 at lindbergh.monkeyblade.net; Sat, 05 Jun 2021 04:05:47 PDT Received: from rhcavspool01.kulnet.kuleuven.be (rhcavspool01.kulnet.kuleuven.be [IPv6:2a02:2c40:0:c0::25:193]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 672CCC061766 for ; Sat, 5 Jun 2021 04:05:47 -0700 (PDT) Received: from icts-p-cavuit-4.kulnet.kuleuven.be (icts-p-cavuit-4.kulnet.kuleuven.be [134.58.240.134]) by rhcavspool01.kulnet.kuleuven.be (Postfix) with ESMTP id 084CC6151 for ; Sat, 5 Jun 2021 12:57:54 +0200 (CEST) X-KULeuven-Envelope-From: mathy.vanhoef@kuleuven.be X-KULeuven-Scanned: Found to be clean X-KULeuven-ID: 7515AC4.AD1A7 X-KULeuven-Information: Katholieke Universiteit Leuven Received: from icts-p-smtps-1.cc.kuleuven.be (icts-p-smtps-1e.kulnet.kuleuven.be [IPv6:2a02:2c40:0:c0::25:33]) by icts-p-cavuit-4.kulnet.kuleuven.be (Postfix) with ESMTP id 7515AC4 for ; Sat, 5 Jun 2021 12:57:33 +0200 (CEST) X-CAV-Cluster: smtps Received: from [172.20.6.62] (bba146567.alshamil.net.ae [217.165.158.9]) (using TLSv1.2 with cipher AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by icts-p-smtps-1.cc.kuleuven.be (Postfix) with ESMTPSA id 4CBD840B2; Sat, 5 Jun 2021 12:57:32 +0200 (CEST) Subject: Re: [PATCH 5.10 024/252] mac80211: prevent mixed key and fragment cache attacks To: Pavel Machek , Greg Kroah-Hartman Cc: linux-kernel@vger.kernel.org, stable@vger.kernel.org, Johannes Berg References: <20210531130657.971257589@linuxfoundation.org> <20210531130658.804599277@linuxfoundation.org> <20210601092619.GA30422@amd> X-Kuleuven: This mail passed the K.U.Leuven mailcluster From: Mathy Vanhoef Message-ID: <52ae0752-422e-b791-365a-228c968ffed9@kuleuven.be> Date: Sat, 5 Jun 2021 14:57:30 +0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.10.1 MIME-Version: 1.0 In-Reply-To: <20210601092619.GA30422@amd> Content-Type: text/plain; charset=windows-1252 Content-Language: en-US Content-Transfer-Encoding: 7bit Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hello Pavel, Good remark. In practice this doesn't look like a problem: the overflow would need to happen in less than two seconds. If it takes longer, the mixed key and cache attack cannot be performed because the previous fragment(s) will be discarded, see https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/net/mac80211/rx.c?h=v5.13-rc4&id=8124c8a6b35386f73523d27eacb71b5364a68c4c#n2202 It may be useful to add this as a comment to the code. Cheers, Mathy On 6/1/21 1:26 PM, Pavel Machek wrote: > Hi! > >> From: Mathy Vanhoef >> >> commit 94034c40ab4a3fcf581fbc7f8fdf4e29943c4a24 upstream. >> >> Simultaneously prevent mixed key attacks (CVE-2020-24587) and fragment >> cache attacks (CVE-2020-24586). This is accomplished by assigning a >> unique color to every key (per interface) and using this to track which >> key was used to decrypt a fragment. When reassembling frames, it is >> now checked whether all fragments were decrypted using the same key. >> >> To assure that fragment cache attacks are also prevented, the ID that is >> assigned to keys is unique even over (re)associations and (re)connects. >> This means fragments separated by a (re)association or (re)connect will >> not be reassembled. Because mac80211 now also prevents the reassembly of >> mixed encrypted and plaintext fragments, all cache attacks are >> prevented. > >> --- a/net/mac80211/key.c >> +++ b/net/mac80211/key.c >> @@ -799,6 +799,7 @@ int ieee80211_key_link(struct ieee80211_ >> struct ieee80211_sub_if_data *sdata, >> struct sta_info *sta) >> { >> + static atomic_t key_color = ATOMIC_INIT(0); >> struct ieee80211_key *old_key; > > This is nice and simple, but does not include any kind of overflow > handling. sparc32 moved away from 24-bit atomics, which is good I > guess. OTOH if this is incremented 10 times a second, we'll still > overflow in 6 years or so. Can attacker make it overflow? > > Should this have a note why overflow is not possible / why it is not a > problem? > > Best regards, > Pavel >