cve-2017-13077 - WPA2 security vulni
Cy Schubert
Cy.Schubert at komquats.com
Mon Oct 16 13:02:12 UTC 2017
In message <21896d6e-75be-3376-bc32-9d911227de5c at freebsd.org>, Stefan Esser
wri
tes:
> Am 16.10.17 um 12:38 schrieb blubee blubeeme:
> > well, that's a cluster if I ever seen one.
> >
> > On Mon, Oct 16, 2017 at 6:35 PM, Poul-Henning Kamp <phk at phk.freebsd.dk>
> > wrote:
> >
> >> --------
> >> In message <CALM2mEmawo7q7GNYLQZPovPVP3dQun5S4Aa4J8Cw2nK8g6Ux4Q at mail.
> >> gmail.com>
> >> , blubee blubeeme writes:
> >>
> >>> Does anyone on FreeBSD know if it's affected by this?
> >>> https://cve.mitre.org/cgi-bin/cvename.cgi?name=2017-13077
> >>
> >> It is, same as Linux, we use the same wpa_supplicant software
>
> The attached patch includes the official patch applied by the WPA
> developers in https://w1.fi/cgit/hostap/commit/?id=a00e946 but
> for our version of wpa_supplicant in /usr/src/contrib.
>
> Regards, STefan
> Index: contrib/wpa/src/rsn_supp/wpa.c
> ===================================================================
> --- contrib/wpa/src/rsn_supp/wpa.c (Revision 324638)
> +++ contrib/wpa/src/rsn_supp/wpa.c (Arbeitskopie)
> @@ -1534,6 +1534,14 @@
> sm->ptk_set = 1;
> os_memcpy(&sm->ptk, &sm->tptk, sizeof(sm->ptk));
> os_memset(&sm->tptk, 0, sizeof(sm->tptk));
> + /*
> + * This assures the same TPTK in sm->tptk can never be
> + * copied twice to sm->pkt as the new PTK. In
> + * combination with the installed flag in the wpa_ptk
> + * struct, this assures the same PTK is only installed
> + * once.
> + */
> + sm->renew_snonce = 1;
> }
> }
>
>
We should also patch the wpa_supplicant and hostapd ports. Also rmove peerkey functionality: http://w1.fi/cgit/hostap/commit/?id=e760851176c77ae6de19821bb1d5bf3ae2cb5187
Looks like hostapd is also affected. Simple for us, not so simple if you've purchased a commodity wirless router. I doubt most of the vendors will do anything.
There are over a dozen (excluding tests and debugging outputs, 16 by my count) commits our upstream have applied to hostapd and wpa_supplicant.
Rather than commit a blob, we should a) mirror their commits which can be MFCed to stable and b) then update head and ports to the latest upstream. B could be MFCed at a later date.
--
Cheers,
Cy Schubert <Cy.Schubert at cschubert.com>
FreeBSD UNIX: <cy at FreeBSD.org> Web: http://www.FreeBSD.org
The need of the many outweighs the greed of the few.
More information about the freebsd-current
mailing list