Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.user > #187924 > unrolled thread

[OT] Breaking WPA2 by forcing nonce reuse

Back to article view | Back to linux.debian.user

Contents

  [OT] Breaking WPA2 by forcing nonce reuse Curt <curty@free.fr> - 2017-10-16 17:50 +0200
    Re: [OT] Breaking WPA2 by forcing nonce reuse "tv.debian@googlemail.com" <tv.debian@googlemail.com> - 2017-10-16 18:00 +0200
      Re: [OT] Breaking WPA2 by forcing nonce reuse "Alexander V. Makartsev" <avbetev@gmail.com> - 2017-10-16 19:00 +0200
        Re: [OT] Breaking WPA2 by forcing nonce reuse Henrique de Moraes Holschuh <hmh@debian.org> - 2017-10-18 15:40 +0200
          Re: [OT] Breaking WPA2 by forcing nonce reuse "tv.debian@googlemail.com" <tv.debian@googlemail.com> - 2017-10-18 19:10 +0200
      Re: [OT] Breaking WPA2 by forcing nonce reuse Celejar <celejar@gmail.com> - 2017-10-16 21:20 +0200
        Re: [OT] Breaking WPA2 by forcing nonce reuse "tv.debian@googlemail.com" <tv.debian@googlemail.com> - 2017-10-17 05:20 +0200
          Re: [OT] Breaking WPA2 by forcing nonce reuse Celejar <celejar@gmail.com> - 2017-10-17 17:00 +0200
            Re: [OT] Breaking WPA2 by forcing nonce reuse Brian <ad44@cityscape.co.uk> - 2017-10-17 20:30 +0200
              Re: [OT] Breaking WPA2 by forcing nonce reuse Celejar <celejar@gmail.com> - 2017-10-19 03:40 +0200
                Re: [OT] Breaking WPA2 by forcing nonce reuse Brian <ad44@cityscape.co.uk> - 2017-10-19 13:10 +0200
                  Re: [OT] Breaking WPA2 by forcing nonce reuse Celejar <celejar@gmail.com> - 2017-10-19 17:10 +0200
                    Re: [OT] Breaking WPA2 by forcing nonce reuse Brian <ad44@cityscape.co.uk> - 2017-10-19 17:40 +0200
                      Re: [OT] Breaking WPA2 by forcing nonce reuse Dan Purgert <dan@djph.net> - 2017-10-19 18:10 +0200
                        Re: [OT] Breaking WPA2 by forcing nonce reuse Ron Leach <ronleach@tesco.net> - 2017-10-19 18:20 +0200
                          Re: [OT] Breaking WPA2 by forcing nonce reuse Brian <ad44@cityscape.co.uk> - 2017-10-20 15:00 +0200
                          Re: [OT] Breaking WPA2 by forcing nonce reuse Dan Purgert <dan@djph.net> - 2017-10-20 19:30 +0200
                      Re: [OT] Breaking WPA2 by forcing nonce reuse Celejar <celejar@gmail.com> - 2017-10-19 18:20 +0200
                        Re: [OT] Breaking WPA2 by forcing nonce reuse "tv.debian@googlemail.com" <tv.debian@googlemail.com> - 2017-10-20 06:40 +0200
                          Re: [OT] Breaking WPA2 by forcing nonce reuse rhkramer@gmail.com - 2017-10-20 17:30 +0200
                          Re: [OT] Breaking WPA2 by forcing nonce reuse Brad Rogers <brad@fineby.me.uk> - 2017-10-20 17:40 +0200
                            Re: [OT] Breaking WPA2 by forcing nonce reuse "tv.debian@googlemail.com" <tv.debian@googlemail.com> - 2017-10-20 18:50 +0200
                    Re: [OT] Breaking WPA2 by forcing nonce reuse <tomas@tuxteam.de> - 2017-10-19 18:10 +0200
                      Re: [OT] Breaking WPA2 by forcing nonce reuse David Wright <deblis@lionunicorn.co.uk> - 2017-10-19 20:50 +0200
                        Re: [OT] Breaking WPA2 by forcing nonce reuse Celejar <celejar@gmail.com> - 2017-10-20 03:00 +0200
                          Re: [OT] Breaking WPA2 by forcing nonce reuse David Wright <deblis@lionunicorn.co.uk> - 2017-10-21 21:30 +0200
    Re: [OT] Breaking WPA2 by forcing nonce reuse Brian <ad44@cityscape.co.uk> - 2017-10-16 22:00 +0200
    Re: [OT] Breaking WPA2 by forcing nonce reuse Larry Dighera <LDighera@att.net> - 2017-10-17 17:30 +0200

Page 1 of 2  [1] 2  Next page →

#187924 — [OT] Breaking WPA2 by forcing nonce reuse

https://www.krackattacks.com/

 Our attack is especially catastrophic against version 2.4 and above of
 wpa_supplicant, a Wi-Fi client commonly used on Linux. Here, the client will
 install an all-zero encryption key instead of reinstalling the real key. 

Uh-oh.


-- 
"A simpering Bambi narcissist and a thieving, fanatical Albanian dwarf."
Christopher Hitchens, commenting shortly after the nearly concurrent deaths 
of Lady Diana and Mother Theresa.

[toc] | [next] | [standalone]

#187925

On 16/10/2017 21:12, Curt wrote:
> https://www.krackattacks.com/
> 
>   Our attack is especially catastrophic against version 2.4 and above of
>   wpa_supplicant, a Wi-Fi client commonly used on Linux. Here, the client will
>   install an all-zero encryption key instead of reinstalling the real key.
> 
> Uh-oh.
> 
> 
  It was addressed in Debian by DSA-3999-1 I think, but will probably 
linger for a long time on routers, phones, appliances and IoT all over 
the world. After Bluetooth a few weeks ago, now wpa2 wifi, most of the 
wireless consumer electronic have it's base covered and ripe for cracking...

[toc] | [prev] | [next] | [standalone]

#187926

[Multipart message — attachments visible in raw view] — view raw

That is one smoking fast update release.
Demo works in perfect environment, but I wonder if there are some
settings on AP that help to prevent successful exploitation of this
vulnerability before(if ever) firmware updates are released by device
manufacturers.
Such as setting re-keying delay to one minute (it is usually 3600sec or
7200sec), so attacker will be forced to perform successful exploitation
every minute.
Or disabling SSID broadcasting and setting channel to fixed value on AP
and client, so this should prevent rogueAP from tricking client to
connect to it.
Also setting power of AP transmitter to the maximum should prevent
situation where client will talk to rogueAP or make it significantly
harder, because rogueAP have to be closer to client.
I'm waiting for PoC scripts release to test it all out.


On 16.10.2017 20:57, tv.debian@googlemail.com wrote:
> On 16/10/2017 21:12, Curt wrote:
>> https://www.krackattacks.com/
>>
>>   Our attack is especially catastrophic against version 2.4 and above of
>>   wpa_supplicant, a Wi-Fi client commonly used on Linux. Here, the
>> client will
>>   install an all-zero encryption key instead of reinstalling the real
>> key.
>>
>> Uh-oh.
>>
>>
>  It was addressed in Debian by DSA-3999-1 I think, but will probably
> linger for a long time on routers, phones, appliances and IoT all over
> the world. After Bluetooth a few weeks ago, now wpa2 wifi, most of the
> wireless consumer electronic have it's base covered and ripe for
> cracking...
>

-- 
With kindest regards, Alexander.

⢀⣴⠾⠻⢶⣦⠀ 
⣾⠁⢠⠒⠀⣿⡁ Debian - The universal operating system
⢿⡄⠘⠷⠚⠋⠀ https://www.debian.org
⠈⠳⣄⠀⠀⠀⠀ 

[toc] | [prev] | [next] | [standalone]

#188011

[Multipart message — attachments visible in raw view] — view raw

On Mon, Oct 16, 2017, at 14:49, Alexander V. Makartsev wrote:
> That is one smoking fast update release. Demo works in perfect
> environment, but I wonder if there are some settings on AP that help
> to prevent successful
Yes, there is.  The AP may refuse to ever resent the third packet of the
4-way handshake if it is lost.  This causes slowdowns on association in
noisy/lossy environments, but safeguards the session key.
Newest openwrt and LEDE and hostapd/WPA git trees have a manual setting
that can do this.  It is not on any release yet,  but might be
available in nightly build images or the updated packages with the
wpa/hostapd binaries.
It obviously protects you only while connected to that AP. You still
want/need a device firmware update or to always use a VPN (or ssh or
https, etc) when using random APs out there...
--
  Henrique de Moraes Holschuh <hmh@debian.org>

[toc] | [prev] | [next] | [standalone]

#188025

On 18/10/2017 19:03, Henrique de Moraes Holschuh wrote:
> On Mon, Oct 16, 2017, at 14:49, Alexander V. Makartsev wrote:
>> That is one smoking fast update release. Demo works in perfect
>> environment, but I wonder if there are some settings on AP that help
>> to prevent successful
> Yes, there is.  The AP may refuse to ever resent the third packet of the
> 4-way handshake if it is lost.  This causes slowdowns on association in
> noisy/lossy environments, but safeguards the session key.
> Newest openwrt and LEDE and hostapd/WPA git trees have a manual setting
> that can do this.  It is not on any release yet,  but might be
> available in nightly build images or the updated packages with the
> wpa/hostapd binaries.
[...]

Hi,

17.01.4 just released [2] with fixed wpa and possibility to activate an 
AP side workaround. It is just a mitigation really, but should in 
practice impair an exploit. It is OFF by default.

Quote:

"an optional AP-side
workaround was introduced in hostapd to complicate these attacks,
slowing them down. Please note that this does not fully protect you from
them, especially when running older versions of wpa_supplicant
vulnerable to CVE-2017-13086, which the workaround does not address. As
this workaround can cause interoperability issues and reduced robustness
of key negotiation, this workaround is disabled by default."

Option in hostapd.sh [1] is:

wpa_disable_eapol_key_retries


[1] 
https://git.lede-project.org/?p=source.git;a=commitdiff;h=d501786ff25684208d22b7c93ce60c194327c771

[2] https://downloads.lede-project.org/releases/17.01.4/targets/

[toc] | [prev] | [next] | [standalone]

#187928

On Mon, 16 Oct 2017 21:27:30 +0530
"tv.debian@googlemail.com" <tv.debian@googlemail.com> wrote:

> On 16/10/2017 21:12, Curt wrote:
> > https://www.krackattacks.com/
> > 
> >   Our attack is especially catastrophic against version 2.4 and above of
> >   wpa_supplicant, a Wi-Fi client commonly used on Linux. Here, the client will
> >   install an all-zero encryption key instead of reinstalling the real key.
> > 
> > Uh-oh.
> > 
> > 
>   It was addressed in Debian by DSA-3999-1 I think, but will probably 
> linger for a long time on routers, phones, appliances and IoT all over 
> the world. After Bluetooth a few weeks ago, now wpa2 wifi, most of the 
> wireless consumer electronic have it's base covered and ripe for cracking...

It's crucial to understand that there's a huge difference in severity
between BlueBorne and and KRACK: the former "allows attackers to take
control of devices", and "does not require the targeted device to be
paired to the attacker’s device, or even to be set on discoverable
mode" (!) [https://www.armis.com/blueborne/], whereas the latter
'simply' breaks WPA2, and can't really hurt you insofar as you're using
secure higher level protocols (ssh, SSL/TSL, HTTPS).

I don't mean to say that KRACK isn't nevertheless a huge problem,
but it doesn't seem to be nearly as serious as BlueBorne, and it isn't
going to be catastrophic to anyone not treating WiFi as a really secure
protocol. E.g., on my home network, I do use WPA, but I still require
SSH and so on for internal communication between my local hosts.

Celejar

[toc] | [prev] | [next] | [standalone]

#187938

On 17/10/2017 00:49, Celejar wrote:
> On Mon, 16 Oct 2017 21:27:30 +0530
> "tv.debian@googlemail.com" <tv.debian@googlemail.com> wrote:
> 
>> On 16/10/2017 21:12, Curt wrote:
>>> https://www.krackattacks.com/
>>>
>>>    Our attack is especially catastrophic against version 2.4 and above of
>>>    wpa_supplicant, a Wi-Fi client commonly used on Linux. Here, the client will
>>>    install an all-zero encryption key instead of reinstalling the real key.
>>>
>>> Uh-oh.
>>>
>>>
>>    It was addressed in Debian by DSA-3999-1 I think, but will probably
>> linger for a long time on routers, phones, appliances and IoT all over
>> the world. After Bluetooth a few weeks ago, now wpa2 wifi, most of the
>> wireless consumer electronic have it's base covered and ripe for cracking...
> 
> It's crucial to understand that there's a huge difference in severity
> between BlueBorne and and KRACK: the former "allows attackers to take
> control of devices", and "does not require the targeted device to be
> paired to the attacker’s device, or even to be set on discoverable
> mode" (!) [https://www.armis.com/blueborne/], whereas the latter
> 'simply' breaks WPA2, and can't really hurt you insofar as you're using
> secure higher level protocols (ssh, SSL/TSL, HTTPS).
> 
> I don't mean to say that KRACK isn't nevertheless a huge problem,
> but it doesn't seem to be nearly as serious as BlueBorne, and it isn't
> going to be catastrophic to anyone not treating WiFi as a really secure
> protocol. E.g., on my home network, I do use WPA, but I still require
> SSH and so on for internal communication between my local hosts.
> 
> Celejar
> 

Agreed, my post was just a quick reaction to an 'OT' labeled thread, not 
a lecture on the respective merits of those vulnerabilities, or an 
attempt to spread F.U.D.. Sorry if it came out this way (not a native 
speaker).

That being said, for a lot of the common use cases having an attacker 
sit on the assumed-to-be secured wifi and able to intercept traffic for 
days, weeks, months maybe since the patching will be as usual "patchy", 
is bad enough. It is not the same as the "bombing the dhcp server and 
throwing everyone off the wifi" prank. From the paper:

"We show that an attacker can force these nonce resets by collecting
and replaying retransmissions of message 3. By forcing nonce reuse
in this manner, the data-confidentiality protocol can be attacked,
e.g., packets can be replayed, decrypted, and/or forged. The same
technique is used to attack the group key, PeerKey, and fast BSS
transition handshake.
When the 4-way or fast BSS transition handshake is attacked,
the precise impact depends on the data-confidentiality protocol
being used. If CCMP is used, arbitrary packets can be decrypted.
In turn, this can be used to decrypt TCP SYN packets, and hijack
TCP connections. For example, an adversary can inject malicious
content into unencrypted HTTP connections. If TKIP or GCMP is
used, an adversary can both decrypt and inject arbitrary packets."

So using https or better for communications on the local network is a 
good idea, but is it the norm? Many router firmwares or built-in 
webservers from cameras to printers default to http, sometime don't even 
offer https as an option.

This isn't as bad as blueborne but it is nonetheless another of the most 
widely used wireless standard being broken in a short time.

It's patched in most distributions, and in router firmwares like LEDE 
already, was patched in some BSD even before publication, but how long 
before we see a patches for all affected devices?

By the way, since we are security OT'ing, check your RSA keys if you 
used Infineon products to generate it.[1]

[1] https://lwn.net/Articles/736520/rss

[toc] | [prev] | [next] | [standalone]

#187978

On Tue, 17 Oct 2017 08:43:00 +0530
"tv.debian@googlemail.com" <tv.debian@googlemail.com> wrote:

> On 17/10/2017 00:49, Celejar wrote:
> > On Mon, 16 Oct 2017 21:27:30 +0530
> > "tv.debian@googlemail.com" <tv.debian@googlemail.com> wrote:

...

> >> the world. After Bluetooth a few weeks ago, now wpa2 wifi, most of the
> >> wireless consumer electronic have it's base covered and ripe for cracking...
> > 
> > It's crucial to understand that there's a huge difference in severity
> > between BlueBorne and and KRACK: the former "allows attackers to take
> > control of devices", and "does not require the targeted device to be
> > paired to the attacker’s device, or even to be set on discoverable
> > mode" (!) [https://www.armis.com/blueborne/], whereas the latter
> > 'simply' breaks WPA2, and can't really hurt you insofar as you're using
> > secure higher level protocols (ssh, SSL/TSL, HTTPS).
> > 
> > I don't mean to say that KRACK isn't nevertheless a huge problem,
> > but it doesn't seem to be nearly as serious as BlueBorne, and it isn't
> > going to be catastrophic to anyone not treating WiFi as a really secure
> > protocol. E.g., on my home network, I do use WPA, but I still require
> > SSH and so on for internal communication between my local hosts.
> > 
> > Celejar
> > 
> 
> Agreed, my post was just a quick reaction to an 'OT' labeled thread, not 
> a lecture on the respective merits of those vulnerabilities, or an 
> attempt to spread F.U.D.. Sorry if it came out this way (not a native 
> speaker).

I actually do agree with what you wrote, I was just trying to add a bit
of detail.

> That being said, for a lot of the common use cases having an attacker 
> sit on the assumed-to-be secured wifi and able to intercept traffic for 
> days, weeks, months maybe since the patching will be as usual "patchy", 
> is bad enough. It is not the same as the "bombing the dhcp server and 

...

> So using https or better for communications on the local network is a 
> good idea, but is it the norm? Many router firmwares or built-in 
> webservers from cameras to printers default to http, sometime don't even 
> offer https as an option.

Yes, after I sent my mail I realized that my wirelessly networked
printer is going to be a problem. Some printers apparently support
access via SSL/TLS (IPPS), but it looks like mine (Brother
HL-2280DW) does not. And what are the odds that Brother will do a
firmware update to patch WPA for this some 6 years old model ;)

> This isn't as bad as blueborne but it is nonetheless another of the most 
> widely used wireless standard being broken in a short time.

Certainly.

> It's patched in most distributions, and in router firmwares like LEDE 
> already, was patched in some BSD even before publication, but how long 
> before we see a patches for all affected devices?

Never - for many / most Android devices, my printer (probably), etc.

> By the way, since we are security OT'ing, check your RSA keys if you 
> used Infineon products to generate it.[1]
> 
> [1] https://lwn.net/Articles/736520/rss

Yeah, just saw that on Ars this morning:

https://arstechnica.com/information-technology/2017/10/crypto-failure-cripples-millions-of-high-security-keys-750k-estonian-ids/

Another day, another critical vulnerability ...

Celejar

[toc] | [prev] | [next] | [standalone]

#187992

On Tue 17 Oct 2017 at 10:57:15 -0400, Celejar wrote:

> On Tue, 17 Oct 2017 08:43:00 +0530
> "tv.debian@googlemail.com" <tv.debian@googlemail.com> wrote:
> 
> > So using https or better for communications on the local network is a 
> > good idea, but is it the norm? Many router firmwares or built-in 
> > webservers from cameras to printers default to http, sometime don't even 
> > offer https as an option.
> 
> Yes, after I sent my mail I realized that my wirelessly networked
> printer is going to be a problem. Some printers apparently support
> access via SSL/TLS (IPPS), but it looks like mine (Brother
> HL-2280DW) does not. And what are the odds that Brother will do a
> firmware update to patch WPA for this some 6 years old model ;)

I, and you, probably, are not dealing with printing confidential
documents. Those entities which are should be more concerned.

Remember, good though the research might be, there is as yet no
published POC and the ideas behind it do not appear particulary
easy to implement. I'm not expecting anyone with the necessary
equipment to be sitting in a car outside my house any time soon.
If I got concerned (and HP did nothing about it) I wonder whether
running arp would do anything to discover what is essentially a
MitM situation?

> > This isn't as bad as blueborne but it is nonetheless another of the most 
> > widely used wireless standard being broken in a short time.
> 
> Certainly.
> 
> > It's patched in most distributions, and in router firmwares like LEDE 
> > already, was patched in some BSD even before publication, but how long 
> > before we see a patches for all affected devices?
> 
> Never - for many / most Android devices, my printer (probably), etc.

A timely fix arrives in Debian. Users who update are once again safe.
What more could you ask for? What can you say apart from "thanks"?

-- 
Brian.

[toc] | [prev] | [next] | [standalone]

#188046

On Tue, 17 Oct 2017 19:20:08 +0100
Brian <ad44@cityscape.co.uk> wrote:

> On Tue 17 Oct 2017 at 10:57:15 -0400, Celejar wrote:
> 
> > On Tue, 17 Oct 2017 08:43:00 +0530
> > "tv.debian@googlemail.com" <tv.debian@googlemail.com> wrote:
> > 
> > > So using https or better for communications on the local network is a 
> > > good idea, but is it the norm? Many router firmwares or built-in 
> > > webservers from cameras to printers default to http, sometime don't even 
> > > offer https as an option.
> > 
> > Yes, after I sent my mail I realized that my wirelessly networked
> > printer is going to be a problem. Some printers apparently support
> > access via SSL/TLS (IPPS), but it looks like mine (Brother
> > HL-2280DW) does not. And what are the odds that Brother will do a
> > firmware update to patch WPA for this some 6 years old model ;)
> 
> I, and you, probably, are not dealing with printing confidential
> documents. Those entities which are should be more concerned.

I'm not? What happens when I need to print out some sort of financial
statement?

...

> > > It's patched in most distributions, and in router firmwares like LEDE 
> > > already, was patched in some BSD even before publication, but how long 
> > > before we see a patches for all affected devices?
> > 
> > Never - for many / most Android devices, my printer (probably), etc.
> 
> A timely fix arrives in Debian. Users who update are once again safe.
> What more could you ask for? What can you say apart from "thanks"?

? Yes, my Debian installations are now safe, and I'm duly thankful to
the Debian maintainers, the wpa_supplicant developers, the LEDE
developers, etc., but why should I not be worried and upset about the
situation with my phone, printer, etc.?

Celejar

[toc] | [prev] | [next] | [standalone]

#188055

On Wed 18 Oct 2017 at 21:30:48 -0400, Celejar wrote:

> On Tue, 17 Oct 2017 19:20:08 +0100
> Brian <ad44@cityscape.co.uk> wrote:
> 
> > On Tue 17 Oct 2017 at 10:57:15 -0400, Celejar wrote:
> > 
> > > On Tue, 17 Oct 2017 08:43:00 +0530
> > > "tv.debian@googlemail.com" <tv.debian@googlemail.com> wrote:
> > > 
> > > > So using https or better for communications on the local network is a 
> > > > good idea, but is it the norm? Many router firmwares or built-in 
> > > > webservers from cameras to printers default to http, sometime don't even 
> > > > offer https as an option.
> > > 
> > > Yes, after I sent my mail I realized that my wirelessly networked
> > > printer is going to be a problem. Some printers apparently support
> > > access via SSL/TLS (IPPS), but it looks like mine (Brother
> > > HL-2280DW) does not. And what are the odds that Brother will do a
> > > firmware update to patch WPA for this some 6 years old model ;)
> > 
> > I, and you, probably, are not dealing with printing confidential
> > documents. Those entities which are should be more concerned.
> 
> I'm not? What happens when I need to print out some sort of financial
> statement?

Ok.

> > > > It's patched in most distributions, and in router firmwares like LEDE 
> > > > already, was patched in some BSD even before publication, but how long 
> > > > before we see a patches for all affected devices?
> > > 
> > > Never - for many / most Android devices, my printer (probably), etc.
> > 
> > A timely fix arrives in Debian. Users who update are once again safe.
> > What more could you ask for? What can you say apart from "thanks"?
> 
> ? Yes, my Debian installations are now safe, and I'm duly thankful to
> the Debian maintainers, the wpa_supplicant developers, the LEDE
> developers, etc., but why should I not be worried and upset about the
> situation with my phone, printer, etc.?

Depends on the level of your concern. There are USB and ethernet
connections to the printer. This might require physical relocation
of the printer but it could be worth it to be worry-free. Or use a 
Debian-based, wireless-enabled print server in close proximity to
the printer.

-- 
Brian.

[toc] | [prev] | [next] | [standalone]

#188059

On Thu, 19 Oct 2017 12:05:23 +0100
Brian <ad44@cityscape.co.uk> wrote:

> On Wed 18 Oct 2017 at 21:30:48 -0400, Celejar wrote:

...

> > developers, etc., but why should I not be worried and upset about the
> > situation with my phone, printer, etc.?
> 
> Depends on the level of your concern. There are USB and ethernet
> connections to the printer. This might require physical relocation
> of the printer but it could be worth it to be worry-free. Or use a 
> Debian-based, wireless-enabled print server in close proximity to
> the printer.

Yes, what I'm probably going to do is use the printer's ethernet
connection along with a Powerline adapter into a nearby power outlet.

Celejar

[toc] | [prev] | [next] | [standalone]

#188061

On Thu 19 Oct 2017 at 11:07:01 -0400, Celejar wrote:

> On Thu, 19 Oct 2017 12:05:23 +0100
> Brian <ad44@cityscape.co.uk> wrote:
> 
> > On Wed 18 Oct 2017 at 21:30:48 -0400, Celejar wrote:
> 
> ...
> 
> > > developers, etc., but why should I not be worried and upset about the
> > > situation with my phone, printer, etc.?
> > 
> > Depends on the level of your concern. There are USB and ethernet
> > connections to the printer. This might require physical relocation
> > of the printer but it could be worth it to be worry-free. Or use a 
> > Debian-based, wireless-enabled print server in close proximity to
> > the printer.
> 
> Yes, what I'm probably going to do is use the printer's ethernet
> connection along with a Powerline adapter into a nearby power outlet.

That's a good idea, but thinking on: there two ends to the connection,
the printer and the sending device. Fixing printers is unlikely to be
high on vendors' lists of priorities, but a fix is available when the
sending device uses Debian. Isn't it sufficient to fix one end of the
connection to dispose of the vulnerability?

-- 
Brian.

[toc] | [prev] | [next] | [standalone]

#188064

Brian wrote:
> [...]
> That's a good idea, but thinking on: there two ends to the connection,
> the printer and the sending device. Fixing printers is unlikely to be
> high on vendors' lists of priorities, but a fix is available when the
> sending device uses Debian. Isn't it sufficient to fix one end of the
> connection to dispose of the vulnerability?
>

KRACK is an attack against the *client* side.  It MUST (rfc2119) be that
device that is patched against the attack.

-- 
|_|O|_| Registered Linux user #585947
|_|_|O| Github: https://github.com/dpurgert
|O|O|O| PGP: 05CA 9A50 3F2E 1335 4DC5  4AEE 8E11 DDF3 1279 A281

[toc] | [prev] | [next] | [standalone]

#188067

On 19/10/2017 16:56, Dan Purgert wrote:
> Brian wrote:
>> [...]
>> Isn't it sufficient to fix one end of the
>> connection to dispose of the vulnerability?
>>
>
> KRACK is an attack against the *client* side.  It MUST (rfc2119) be that
> device that is patched against the attack.
>

Dan, I'm not sure it's that simple, either.

There are *two* WiFi connections in the Debian-box to Printer case:
i Debian box to Access Point
ii Printer to Access Point

Brian's idea is good for the connection from the Debian box to the 
Access Point1.

But the connection between the printer, and the Access Point remains 
vulnerable - particularly to the possible all-zero key.

Your advice is extremely close, and very pertinent, but *both* clients 
need to be fixed.  So Celejar's powerline link may be a reasonable 
solution for his case.

regards, Ron

[toc] | [prev] | [next] | [standalone]

#188122

On Thu 19 Oct 2017 at 17:06:20 +0100, Ron Leach wrote:

> On 19/10/2017 16:56, Dan Purgert wrote:
> > Brian wrote:
> > > [...]
> > > Isn't it sufficient to fix one end of the
> > > connection to dispose of the vulnerability?
> > > 
> > 
> > KRACK is an attack against the *client* side.  It MUST (rfc2119) be that
> > device that is patched against the attack.
> > 
> 
> Dan, I'm not sure it's that simple, either.
> 
> There are *two* WiFi connections in the Debian-box to Printer case:
> i Debian box to Access Point
> ii Printer to Access Point
> 
> Brian's idea is good for the connection from the Debian box to the Access
> Point1.
> 
> But the connection between the printer, and the Access Point remains
> vulnerable - particularly to the possible all-zero key.
> 
> Your advice is extremely close, and very pertinent, but *both* clients need
> to be fixed.  So Celejar's powerline link may be a reasonable solution for
> his case.

Thanks to you, Dan Purgert and Celejar for correcting my misconception.
The middleman (the WAP) needs to be taken out of the picture. With more
recent printers this is a possibility if they have WiFi Direct. A Debian
machine with a patched supplicant can then be set up to connect directly
with the printer.

-- 
Brian.

[toc] | [prev] | [next] | [standalone]

#188131

Ron Leach wrote:
> On 19/10/2017 16:56, Dan Purgert wrote:
>> Brian wrote:
>>> [...]
>>> Isn't it sufficient to fix one end of the
>>> connection to dispose of the vulnerability?
>>>
>>
>> KRACK is an attack against the *client* side.  It MUST (rfc2119) be that
>> device that is patched against the attack.
>>
>
> Dan, I'm not sure it's that simple, either.
> [...]
>
> Your advice is extremely close, and very pertinent, but *both* clients 
> need to be fixed.  

I read his comment as "one side" being the AP side in the AP/Client
relationship ... not that you'd only need to patch "one client".

To be as clear as possible -- Any and all client devices MUST (rfc2119)
be patched to be secure from the KRACK attack.

-- 
|_|O|_| Registered Linux user #585947
|_|_|O| Github: https://github.com/dpurgert
|O|O|O| PGP: 05CA 9A50 3F2E 1335 4DC5  4AEE 8E11 DDF3 1279 A281

[toc] | [prev] | [next] | [standalone]

#188066

On Thu, 19 Oct 2017 16:39:34 +0100
Brian <ad44@cityscape.co.uk> wrote:

> On Thu 19 Oct 2017 at 11:07:01 -0400, Celejar wrote:
> 
> > On Thu, 19 Oct 2017 12:05:23 +0100
> > Brian <ad44@cityscape.co.uk> wrote:
> > 
> > > On Wed 18 Oct 2017 at 21:30:48 -0400, Celejar wrote:
> > 
> > ...
> > 
> > > > developers, etc., but why should I not be worried and upset about the
> > > > situation with my phone, printer, etc.?
> > > 
> > > Depends on the level of your concern. There are USB and ethernet
> > > connections to the printer. This might require physical relocation
> > > of the printer but it could be worth it to be worry-free. Or use a 
> > > Debian-based, wireless-enabled print server in close proximity to
> > > the printer.
> > 
> > Yes, what I'm probably going to do is use the printer's ethernet
> > connection along with a Powerline adapter into a nearby power outlet.
> 
> That's a good idea, but thinking on: there two ends to the connection,
> the printer and the sending device. Fixing printers is unlikely to be
> high on vendors' lists of priorities, but a fix is available when the
> sending device uses Debian. Isn't it sufficient to fix one end of the
> connection to dispose of the vulnerability?

As I understand it, when I print something from some device (say, my
Debian laptop), the device establishes a TCP/IP connection with the
printer to do the printing. In my (typical) setup, at the link level,
the device connects to the AP / switch / router wirelessly (via WPA2),
and so does the printer. Assuming the device and router are both
patched, the link between the device and the router is secure, but the
link between the router and printer is not, so any data I send between
the device and the printer will be secure as it traverses the first
link, but not the second. As I understand things, patching the router
doesn't really help secure the link between it and vulnerable devices
like the printer. Henrique recently noted that there is a setting
available on new OpenWRT and LEDE builds that can help, but it's
apparently not yet included in any release yet:

https://lists.debian.org/debian-user/2017/10/msg00593.html

Celejar

[toc] | [prev] | [next] | [standalone]

#188112

On 19/10/2017 21:42, Celejar wrote

[...]
> like the printer. Henrique recently noted that there is a setting
> available on new OpenWRT and LEDE builds that can help, but it's
> apparently not yet included in any release yet:
> 
> https://lists.debian.org/debian-user/2017/10/msg00593.html
> 
> Celejar
> 

I sent that a day ago, but for some reason it didn't make it to the list:

> Hi,
> 
> 17.01.4 just released [2] with fixed wpa and possibility to activate an AP side workaround. It is just a mitigation really, but should in practice impair an exploit. It is OFF by default.
> 
> Quote:
> 
> "an optional AP-side
> workaround was introduced in hostapd to complicate these attacks,
> slowing them down. Please note that this does not fully protect you from
> them, especially when running older versions of wpa_supplicant
> vulnerable to CVE-2017-13086, which the workaround does not address. As
> this workaround can cause interoperability issues and reduced robustness
> of key negotiation, this workaround is disabled by default."
> 
> Option in hostapd.sh [1] is:
> 
> wpa_disable_eapol_key_retries
> 
> 
> [1] https://git.lede-project.org/?p=source.git;a=commitdiff;h=d501786ff25684208d22b7c93ce60c194327c771
> 
> [2] https://downloads.lede-project.org/releases/17.01.4/targets/

So it is part of Latest LEDE release, but I am not aware of other distro 
using this workaround. It comes with a few potential problems, so must 
be thoroughly tested before being deployed, and it likely breaks 
standards which is never good.

[toc] | [prev] | [next] | [standalone]

#188124

On Friday, October 20, 2017 12:35:34 AM tv.debian@googlemail.com wrote:
> I sent that a day ago, but for some reason it didn't make it to the list:

Why do you think it didn't make it to the list?  I received it on Wednesday, 
with the same quote listed below--here are the headers:

<quote>
Re: [OT] Breaking WPA2 by forcing nonce reuse
From: "tv.debian@googlemail.com" <tv.debian@googlemail.com> (resent from 
debian-user@lists.debian.org)
  To: debian-user@lists.debian.org
  Date: Wed Oct 18 13:04:04 2017
</quote>

I suspect that, like for many email users / clients, some combination of the 
ISP, your email client, and the maillist headers keep you from seeing your own 
posts.


The following quote was in the Wednesday post:
> > Quote:
> > 
> > "an optional AP-side
> > workaround was introduced in hostapd to complicate these attacks,
> > slowing them down. Please note that this does not fully protect you from
> > them, especially when running older versions of wpa_supplicant
> > vulnerable to CVE-2017-13086, which the workaround does not address. As
> > this workaround can cause interoperability issues and reduced robustness
> > of key negotiation, this workaround is disabled by default."
> > 
> > Option in hostapd.sh [1] is:
> > 
> > wpa_disable_eapol_key_retries
> > 
> > 
> > [1]
> > https://git.lede-project.org/?p=source.git;a=commitdiff;h=d501786ff25684
> > 208d22b7c93ce60c194327c771
> > 
> > [2] https://downloads.lede-project.org/releases/17.01.4/targets/
> 
> So it is part of Latest LEDE release, but I am not aware of other distro
> using this workaround. It comes with a few potential problems, so must
> be thoroughly tested before being deployed, and it likely breaks
> standards which is never good.

[toc] | [prev] | [next] | [standalone]

Page 1 of 2  [1] 2  Next page →

Back to top | Article view | linux.debian.user

csiph-web