Hello!
ESET engineers on their blog published some information about new
security vulnerability CVE-2020-3702 in ath9k wifi cards:
https://www.welivesecurity.com/2020/08/06/beyond-kr00k-even-more-wifi-chips-vulnerable-eavesdropping/
According to Qualcomm security bulletin this CVE-2020-3702 affects also
some Qualcomm IPQ chips which are handled by ath10k driver:
https://www.qualcomm.com/company/product-security/bulletins/august-2020-security-bulletin#_cve-2020-3702
Kalle, could you or other people from Qualcomm provide updated and fixed
version of ath9k and ath10k firmwares in linux-firmware git repository?
According to Qualcomm security bulletin this issue has Critical security
rating, so I think fixed firmware files should be updated also in stable
releases of linux distributions.
On Monday 10 August 2020 11:01:26 Pali Rohár wrote:
> Hello!
>
> ESET engineers on their blog published some information about new
> security vulnerability CVE-2020-3702 in ath9k wifi cards:
> https://www.welivesecurity.com/2020/08/06/beyond-kr00k-even-more-wifi-chips-vulnerable-eavesdropping/
>
> According to Qualcomm security bulletin this CVE-2020-3702 affects also
> some Qualcomm IPQ chips which are handled by ath10k driver:
> https://www.qualcomm.com/company/product-security/bulletins/august-2020-security-bulletin#_cve-2020-3702
>
> Kalle, could you or other people from Qualcomm provide updated and fixed
> version of ath9k and ath10k firmwares in linux-firmware git repository?
>
> According to Qualcomm security bulletin this issue has Critical security
> rating, so I think fixed firmware files should be updated also in stable
> releases of linux distributions.
Hello!
Qualcomm has already sent following statement to media:
Qualcomm has already made mitigations available to OEMs in May 2020,
and we encourage end users to update their devices as patches have
become available from OEMs.
And based on information from ESET blog post, Qualcomm's proprietary
driver for these wifi cards is fixed since Qualcomm July release.
Could somebody react and provide some details when fixes would be
available for ath9k and ath10k Linux drivers? And what is current state
of this issue for Linux?
I'm looking at ath9k and ath10k git trees [1] [2] [3] and I do not see
there any change which could be related to CVE-2020-3702.
Based on ESET tests, wifi cards which use ath9k driver (opensource, not
that Qualcomm proprietary) are still vulnerable.
[1] - https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git/log/ath10k
[2] - https://git.kernel.org/pub/scm/linux/kernel/git/kvalo/ath.git/log/drivers/net/wireless/ath/ath10k?h=master-pending
[3] - https://git.kernel.org/pub/scm/linux/kernel/git/kvalo/ath.git/log/drivers/net/wireless/ath/ath9k?h=master-pending
Pali Rohár <[email protected]> writes:
> On Monday 10 August 2020 11:01:26 Pali Rohár wrote:
>> Hello!
>>
>> ESET engineers on their blog published some information about new
>> security vulnerability CVE-2020-3702 in ath9k wifi cards:
>> https://www.welivesecurity.com/2020/08/06/beyond-kr00k-even-more-wifi-chips-vulnerable-eavesdropping/
>>
>> According to Qualcomm security bulletin this CVE-2020-3702 affects also
>> some Qualcomm IPQ chips which are handled by ath10k driver:
>> https://www.qualcomm.com/company/product-security/bulletins/august-2020-security-bulletin#_cve-2020-3702
>>
>> Kalle, could you or other people from Qualcomm provide updated and fixed
>> version of ath9k and ath10k firmwares in linux-firmware git repository?
>>
>> According to Qualcomm security bulletin this issue has Critical security
>> rating, so I think fixed firmware files should be updated also in stable
>> releases of linux distributions.
>
> Hello!
>
> Qualcomm has already sent following statement to media:
>
> Qualcomm has already made mitigations available to OEMs in May 2020,
> and we encourage end users to update their devices as patches have
> become available from OEMs.
>
> And based on information from ESET blog post, Qualcomm's proprietary
> driver for these wifi cards is fixed since Qualcomm July release.
>
> Could somebody react and provide some details when fixes would be
> available for ath9k and ath10k Linux drivers? And what is current state
> of this issue for Linux?
>
> I'm looking at ath9k and ath10k git trees [1] [2] [3] and I do not see
> there any change which could be related to CVE-2020-3702.
How about these, from March:
a0761a301746 ("mac80211: drop data frames without key on encrypted links")
ce2e1ca70307 ("mac80211: Check port authorization in the ieee80211_tx_dequeue() case")
b16798f5b907 ("mac80211: mark station unauthorized before key removal")
-Toke
On Wed, Aug 12, 2020 at 11:17:47AM +0200, Toke Høiland-Jørgensen wrote:
> Pali Rohár <[email protected]> writes:
> > Could somebody react and provide some details when fixes would be
> > available for ath9k and ath10k Linux drivers? And what is current state
> > of this issue for Linux?
> >
> > I'm looking at ath9k and ath10k git trees [1] [2] [3] and I do not see
> > there any change which could be related to CVE-2020-3702.
>
> How about these, from March:
>
> a0761a301746 ("mac80211: drop data frames without key on encrypted links")
> ce2e1ca70307 ("mac80211: Check port authorization in the ieee80211_tx_dequeue() case")
> b16798f5b907 ("mac80211: mark station unauthorized before key removal")
Those cover most of the identified issues for drivers using mac80211
(e.g., ath9k and ath10k; though, I don't remember whether I actually
ever managed to reproduce this with ath10k in practice). I have couple
of additional ath9k-specific patches that cover additional lower layer
paths for this. I hope to get those out after confirming they work with
the current kernel tree snapshot.
--
Jouni Malinen PGP id EFC895FA
On Wednesday 12 August 2020 11:17:47 Toke Høiland-Jørgensen wrote:
> Pali Rohár <[email protected]> writes:
>
> > On Monday 10 August 2020 11:01:26 Pali Rohár wrote:
> >> Hello!
> >>
> >> ESET engineers on their blog published some information about new
> >> security vulnerability CVE-2020-3702 in ath9k wifi cards:
> >> https://www.welivesecurity.com/2020/08/06/beyond-kr00k-even-more-wifi-chips-vulnerable-eavesdropping/
> >>
> >> According to Qualcomm security bulletin this CVE-2020-3702 affects also
> >> some Qualcomm IPQ chips which are handled by ath10k driver:
> >> https://www.qualcomm.com/company/product-security/bulletins/august-2020-security-bulletin#_cve-2020-3702
> >>
> >> Kalle, could you or other people from Qualcomm provide updated and fixed
> >> version of ath9k and ath10k firmwares in linux-firmware git repository?
> >>
> >> According to Qualcomm security bulletin this issue has Critical security
> >> rating, so I think fixed firmware files should be updated also in stable
> >> releases of linux distributions.
> >
> > Hello!
> >
> > Qualcomm has already sent following statement to media:
> >
> > Qualcomm has already made mitigations available to OEMs in May 2020,
> > and we encourage end users to update their devices as patches have
> > become available from OEMs.
> >
> > And based on information from ESET blog post, Qualcomm's proprietary
> > driver for these wifi cards is fixed since Qualcomm July release.
> >
> > Could somebody react and provide some details when fixes would be
> > available for ath9k and ath10k Linux drivers? And what is current state
> > of this issue for Linux?
> >
> > I'm looking at ath9k and ath10k git trees [1] [2] [3] and I do not see
> > there any change which could be related to CVE-2020-3702.
>
> How about these, from March:
>
> a0761a301746 ("mac80211: drop data frames without key on encrypted links")
> ce2e1ca70307 ("mac80211: Check port authorization in the ieee80211_tx_dequeue() case")
> b16798f5b907 ("mac80211: mark station unauthorized before key removal")
Thank you for update! I will look at these commits if they are relevant.
Because ESET wrote that problem is in ath9k driver I have not looked at
mac80211 layer code.
> -Toke
>
On Wed, 12 Aug 2020 at 11:26, Jouni Malinen <[email protected]> wrote:
>
> On Wed, Aug 12, 2020 at 11:17:47AM +0200, Toke Høiland-Jørgensen wrote:
> > Pali Rohár <[email protected]> writes:
> > > Could somebody react and provide some details when fixes would be
> > > available for ath9k and ath10k Linux drivers? And what is current state
> > > of this issue for Linux?
> > >
> > > I'm looking at ath9k and ath10k git trees [1] [2] [3] and I do not see
> > > there any change which could be related to CVE-2020-3702.
> >
> > How about these, from March:
> >
> > a0761a301746 ("mac80211: drop data frames without key on encrypted links")
> > ce2e1ca70307 ("mac80211: Check port authorization in the ieee80211_tx_dequeue() case")
> > b16798f5b907 ("mac80211: mark station unauthorized before key removal")
>
> Those cover most of the identified issues for drivers using mac80211
> (e.g., ath9k and ath10k; though, I don't remember whether I actually
> ever managed to reproduce this with ath10k in practice). I have couple
> of additional ath9k-specific patches that cover additional lower layer
> paths for this. I hope to get those out after confirming they work with
> the current kernel tree snapshot.
As far as I understand the problem can manifest on partial in-hw ampdu
retransmits if a key was removed in between. Not exactly an easy thing
to reproduce. The actual drivers (ath9k, ath10k) or their microcodes
may need to be fixed as well since mac80211 can only do so much.
Michal
Pali Rohár <[email protected]> writes:
> ESET engineers on their blog published some information about new
> security vulnerability CVE-2020-3702 in ath9k wifi cards:
> https://www.welivesecurity.com/2020/08/06/beyond-kr00k-even-more-wifi-chips-vulnerable-eavesdropping/
>
> According to Qualcomm security bulletin this CVE-2020-3702 affects also
> some Qualcomm IPQ chips which are handled by ath10k driver:
> https://www.qualcomm.com/company/product-security/bulletins/august-2020-security-bulletin#_cve-2020-3702
I can't find any refererences to ath10k, or hardware with ath10k
chipsets, in the links above. Where did you see it?
--
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
On Monday 17 August 2020 12:58:52 Kalle Valo wrote:
> Pali Rohár <[email protected]> writes:
>
> > ESET engineers on their blog published some information about new
> > security vulnerability CVE-2020-3702 in ath9k wifi cards:
> > https://www.welivesecurity.com/2020/08/06/beyond-kr00k-even-more-wifi-chips-vulnerable-eavesdropping/
> >
> > According to Qualcomm security bulletin this CVE-2020-3702 affects also
> > some Qualcomm IPQ chips which are handled by ath10k driver:
> > https://www.qualcomm.com/company/product-security/bulletins/august-2020-security-bulletin#_cve-2020-3702
>
> I can't find any refererences to ath10k, or hardware with ath10k
> chipsets, in the links above. Where did you see it?
Now I'm looking at that security bulletin for CVE-2020-3702 and it
contains different list of affected chipset as at time when I wrote
previous email. Previously there were IPQ ath10k chipsets and no AR
chipsets. Now there are lot of ath9k AR9xxx and none of IPQ.
So meanwhile Qualcomm changed vulnerability list.
On Wednesday 12 August 2020 12:23:34 Jouni Malinen wrote:
> On Wed, Aug 12, 2020 at 11:17:47AM +0200, Toke Høiland-Jørgensen wrote:
> > Pali Rohár <[email protected]> writes:
> > > Could somebody react and provide some details when fixes would be
> > > available for ath9k and ath10k Linux drivers? And what is current state
> > > of this issue for Linux?
> > >
> > > I'm looking at ath9k and ath10k git trees [1] [2] [3] and I do not see
> > > there any change which could be related to CVE-2020-3702.
> >
> > How about these, from March:
> >
> > a0761a301746 ("mac80211: drop data frames without key on encrypted links")
> > ce2e1ca70307 ("mac80211: Check port authorization in the ieee80211_tx_dequeue() case")
> > b16798f5b907 ("mac80211: mark station unauthorized before key removal")
>
> Those cover most of the identified issues for drivers using mac80211
> (e.g., ath9k and ath10k; though, I don't remember whether I actually
> ever managed to reproduce this with ath10k in practice). I have couple
> of additional ath9k-specific patches that cover additional lower layer
> paths for this. I hope to get those out after confirming they work with
> the current kernel tree snapshot.
Hello! Could you please share your ath9k patches which address this issue?
On Wednesday 07 October 2020 10:25:02 Pali Rohár wrote:
> On Wednesday 12 August 2020 12:23:34 Jouni Malinen wrote:
> > On Wed, Aug 12, 2020 at 11:17:47AM +0200, Toke Høiland-Jørgensen wrote:
> > > Pali Rohár <[email protected]> writes:
> > > > Could somebody react and provide some details when fixes would be
> > > > available for ath9k and ath10k Linux drivers? And what is current state
> > > > of this issue for Linux?
> > > >
> > > > I'm looking at ath9k and ath10k git trees [1] [2] [3] and I do not see
> > > > there any change which could be related to CVE-2020-3702.
> > >
> > > How about these, from March:
> > >
> > > a0761a301746 ("mac80211: drop data frames without key on encrypted links")
> > > ce2e1ca70307 ("mac80211: Check port authorization in the ieee80211_tx_dequeue() case")
> > > b16798f5b907 ("mac80211: mark station unauthorized before key removal")
> >
> > Those cover most of the identified issues for drivers using mac80211
> > (e.g., ath9k and ath10k; though, I don't remember whether I actually
> > ever managed to reproduce this with ath10k in practice). I have couple
> > of additional ath9k-specific patches that cover additional lower layer
> > paths for this. I hope to get those out after confirming they work with
> > the current kernel tree snapshot.
>
> Hello! Could you please share your ath9k patches which address this issue?
Hello! Has somebody fixes this security issue in ath9k driver? About
4 months passed and if this issue is not fixed, could you please share
at least incomplete / WIP patches? I would like to look at it and have
this issue finally fixed.
On Mon, Dec 07, 2020 at 03:04:38PM +0100, Pali Rohár wrote:
> Hello! Has somebody fixes this security issue in ath9k driver? About
> 4 months passed and if this issue is not fixed, could you please share
> at least incomplete / WIP patches? I would like to look at it and have
> this issue finally fixed.
https://patchwork.kernel.org/project/linux-wireless/list/?series=401685
--
Jouni Malinen PGP id EFC895FA
On Monday 14 December 2020 19:41:49 Jouni Malinen wrote:
> On Mon, Dec 07, 2020 at 03:04:38PM +0100, Pali Rohár wrote:
> > Hello! Has somebody fixes this security issue in ath9k driver? About
> > 4 months passed and if this issue is not fixed, could you please share
> > at least incomplete / WIP patches? I would like to look at it and have
> > this issue finally fixed.
>
> https://patchwork.kernel.org/project/linux-wireless/list/?series=401685
Thank you! I will look at it.