KRACK vulnerability

Moderators: grovkillen, Stuntteam, TD-er

Post Reply
Message
Author
s0170071
Normal user
Posts: 36
Joined: 21 Oct 2017, 20:49

KRACK vulnerability

#1 Post by s0170071 » 21 Oct 2017, 21:44

Hi all,

I just tried the new 2.4.0rc2 Arduino library as it has the latest WPA2 "Krack" vulnerability fixed.
https://github.com/esp8266/Arduino/rele ... /2.4.0-rc2
Good news: compiles and seems to run. Fast as lighning :D :D :D They changed the TCP acknowledge behaviour which makes the ESP considerably more responsive.


Issue:
-has some stray characters in the web interface. E.g. 65a 1b2 1ac on the main page right above "system info". A "48" above "powered by..." and a "0" below. See attachment.
-It does restart /crash after an hour or so.

Any Ideas (other than waiting for the final 2.4.0) ? Remember: it is really much faster than 2.3.0 and definately worth a try.
Attachments
2017-10-21_22h23_38.png
2017-10-21_22h23_38.png (23.2 KiB) Viewed 11008 times

User avatar
enesbcs
Normal user
Posts: 587
Joined: 18 Jun 2017, 11:02
Location: Békéscsaba, Hungary
Contact:

Re: KRACK vulnerability

#2 Post by enesbcs » 22 Oct 2017, 09:21

s0170071 wrote: 21 Oct 2017, 21:44 Issue:
-has some stray characters in the web interface. E.g. 65a 1b2 1ac on the main page right above "system info". A "48" above "powered by..." and a "0" below. See attachment.
-It does restart /crash after an hour or so.

Any Ideas (other than waiting for the final 2.4.0) ? Remember: it is really much faster than 2.3.0 and definately worth a try.
In ESPEasy webserver.ino in the "sendWebPageChunkedData(String& log, String& data)" function there are a line:

WebServer.sendContent(size);

And in sendWebPageChunkedEnd(String& log)

WebServer.sendContent("0\r\n\r\n");

if you comment them out, the strange numbers will not appear. I do not know what was the idea behind, but i hope someday it will be fixed.

I have no clue about the restart, maybe some memory leaking error... what ESPEasy version did you try? dev11,dev12 or github current?

User avatar
vader
Normal user
Posts: 241
Joined: 21 Mar 2017, 17:35

Re: KRACK vulnerability

#3 Post by vader » 22 Oct 2017, 12:26

Ok, it works. But, webserver.ino is part of ESP Easy not the core! So, there must be somewhere a trigger from the core that ESP Easy shows that values. With 2.3.0 that values are not shown... :?

Update: I flashed all my ESPs with 2.4.0. core now. Let's see what's happening.... :mrgreen:

s0170071
Normal user
Posts: 36
Joined: 21 Oct 2017, 20:49

Re: KRACK vulnerability

#4 Post by s0170071 » 23 Oct 2017, 06:57

well, the crashes I had may acutally be owed to the fact that I accidentally compiled with debug mode on. I had some debug messages from the visual micro debugger in the serial ouput. I retried without - it seems to work so far.

The removal of the WebServer.sendContent(size); fixed the stray numbers issue for 2.4.0rc2, it did however, break the webpage generation for 2.3.0. :?

s0170071
Normal user
Posts: 36
Joined: 21 Oct 2017, 20:49

Re: KRACK vulnerability

#5 Post by s0170071 » 05 Nov 2017, 21:54

Hi vader,
found my problem.

Basicly the ESP runs fine as long as I access it from my lan only. When I try to access it from my Android device via VPN through my FritzBox 7490 I do not get a webpage displayed. The ESP hangs - times out somewhere and has about 5k ram less free. Do it three times in a row and it crashes. Let it alone for a while and it recovers.
I have tried to track the bug but have not have success yet.

manjh
Normal user
Posts: 516
Joined: 08 Feb 2016, 11:22

Re: KRACK vulnerability

#6 Post by manjh » 05 Nov 2017, 22:48

Strange, I do exactly that! I run a VPN server on the Pi that also runs Domoticz, and whenever I want to access the ESP units from outside my own LAN, I connect a VPN tunnel and simply connect to the ESP. Have never experienced a problem like you describe.
There must be something special going on here!

s0170071
Normal user
Posts: 36
Joined: 21 Oct 2017, 20:49

Re: KRACK vulnerability

#7 Post by s0170071 » 05 Nov 2017, 23:48

I think I nailed it.
I can now recieve with my mobile device via VPN. What I did was modifying the chunked data transfer function so that it
- does only send chunks <1400 bytes
- call delay(30) after each chunk or wait for the heap memory to return.
- does no "real" chunking as part of it (announcing the size) is done by the firmware now.

I played a bit with the chunk size and think it is no coincidence that the max. working size is between 1400 and 1500. It is about the size of a TCP packet payload.
There must be some sort of race condition in the firmware.

Code: Select all

void sendWebPageChunkedData(String& log, String& data)
{
	String tmp;
	delay(20);
	checkRAM(F("sendWebPageChunkedData"));
  if (data.length() > 0)
  {
    statusLED(true);
    log += F(" [");
    log += data.length();
    log += F("]");
    String size;
    size=String(data.length(), HEX)+"\r\n";
 
    //do chunked transfer encoding ourselfs (WebServer doesnt support it)
	#define MAXSIZECH 1300
	int i = 0;
	int memory = 0; 
	int timeout = 0;

	// split into chunks of MAXSIZECH
	for (int l = 0; l < (data.length() / MAXSIZECH);l++) {
		tmp = data.substring(i, i+ MAXSIZECH);			// prepare tmp string for passing to sendContent()
 		
 		memory = ESP.getFreeHeap();					// available memory before send
		timeout = 0; 								// init timeout
		WebServer.sendContent(tmp);
 		i = i + MAXSIZECH;
		while ((ESP.getFreeHeap() < memory)&&(timeout <50)) {	// wait for memory to return or the timeout
			delay(5);	
			timeout++;				
			}
		}
		
	// send remainder	
	tmp = data.substring(i, data.length());
	timeout = 0;
	memory = ESP.getFreeHeap();					// available memory befor send
	WebServer.sendContent(tmp);
	while ((ESP.getFreeHeap() < memory) && (timeout <50)) {	// wait for memory to return
		delay(5);
		timeout++;
	}

    data = F("");   //free RAM
    tmp = F("");
  }
}


void sendWebPageChunkedEnd(String& log)
{
  log += F(" [0]");
   WebServer.sendContent("");
   WebServer.client().flush();
   WebServer.client().stop();
}



Instead of waiting for the memory to return, a delay of 30 ms after each sendContent() works too.


@manjh,
are you running the 2.4.0rc2 core ? Tools->info-> core version. Just asking because 2.3.0 was running fine with me too. It was 2.4.0rc2 that was causing the trouble.
Last edited by s0170071 on 06 Nov 2017, 21:23, edited 2 times in total.

User avatar
enesbcs
Normal user
Posts: 587
Joined: 18 Jun 2017, 11:02
Location: Békéscsaba, Hungary
Contact:

Re: KRACK vulnerability

#8 Post by enesbcs » 06 Nov 2017, 07:32

s0170071 wrote: 05 Nov 2017, 23:48 I think I nailed it.
I can now recieve with my mobile device via VPN. What I did was modifying the chunked data transfer function so that it
- does only send chunks <1400 bytes
- call delay(10) after each packet.
- does no "real" chunking as part of it (announcing the size) is done by the firmware now.

I played a bit with the chunk size and think it is no coincidence that the max. working size is between 1400 and 1500. It is about the size of a TCP packet payload.
There must be some sort of race condition in the firmware.
I think that packet size is a plausible guess.. but how did you find 10 milliseconds?

s0170071
Normal user
Posts: 36
Joined: 21 Oct 2017, 20:49

Re: KRACK vulnerability

#9 Post by s0170071 » 06 Nov 2017, 08:28

I found the 10 mseconds by trial and error.
The code I posted will get updated tonight as it fails with the "hardware" page. This page is about 8kb and string handling as I implemented it fails due to low memory. (exception 3) I fixed that this morning but cannot post the update until tonight as it resides on another machine.
- I just updated it . The code above works for me now.


I need to check but it seems like WebServer.sendContent() its non blocking. That means that the data buffer should remain untouched as long as the packets are not sent- unless they copy all the data to a private buffer. Strange thing is that the bug only shows when I connect through VPN. I still think it has somtheing to do with timimg.
Btw. The delay is now 20ms.

Is there a method that indicated if the stack is still busy sending ? I did google but did not find it. I would need such a busy indication for some sensors as well .The wifi interferes with analog signal processing of my SHT25 sensors. I fixed that with a delay too, but it is probably longer than absolutely necessary.
Last edited by s0170071 on 06 Nov 2017, 20:48, edited 1 time in total.

TD-er
Core team member
Posts: 8739
Joined: 01 Sep 2017, 22:13
Location: the Netherlands
Contact:

Re: KRACK vulnerability

#10 Post by TD-er » 06 Nov 2017, 13:50

If communication is tunneled (e.g. via VPN), it may well be the MTU of 1500 is somewhere exceeded.
So lowering it to 1400-something may fix it, but it is an indication of the source of the problems.

s0170071
Normal user
Posts: 36
Joined: 21 Oct 2017, 20:49

Re: KRACK vulnerability

#11 Post by s0170071 » 07 Nov 2017, 06:45

I was suspecting something like that. Maybe its related to a known issue.
https://github.com/esp8266/Arduino/issues/2437
It does not look like this gets fixed any time soon though.

But with the workaround I published above website generation runs smoothly now. :D

However, I found another issue. Its the system %variables%. When I enter somthing like

Code: Select all

U: %uptime%
as a line for my OLED display, after "submit" the line in the webform just reads "U: ". Everything after from the % is lost. Tried it with two browsers.
If you surround it with quotes "%" - the line stays. All other lines with sensor variables remain untouched.

Any ideas where to start searching ?

s0170071
Normal user
Posts: 36
Joined: 21 Oct 2017, 20:49

Re: KRACK vulnerability

#12 Post by s0170071 » 07 Nov 2017, 13:37

just found out: if I enter %25uptime%25 - which is the URL encoding style- the setting goes through.
However, it crashes the ESP in the course.

User avatar
vader
Normal user
Posts: 241
Joined: 21 Mar 2017, 17:35

Re: KRACK vulnerability

#13 Post by vader » 07 Nov 2017, 13:49

No problem with that.

HELLO
%uptime%

on OLED give this:
Attachments
Display.jpg
Display.jpg (11.51 KiB) Viewed 10651 times

s0170071
Normal user
Posts: 36
Joined: 21 Oct 2017, 20:49

Re: KRACK vulnerability

#14 Post by s0170071 » 07 Nov 2017, 14:13

Hi vader,

I remember using it myself. However, I do now migrate to the 2.4.0 rc2 arduino core for a number of reasons. Which core do you use ? Tools->info-> Core Version.
The issue may be related to
https://github.com/esp8266/Arduino/issues/1989

User avatar
vader
Normal user
Posts: 241
Joined: 21 Mar 2017, 17:35

Re: KRACK vulnerability

#15 Post by vader » 07 Nov 2017, 15:41

That issue is already from 29 Apr 2016 and should be fixed. I tried core 2.4 and reverted back to 2.3 due to some problems it made....

s0170071
Normal user
Posts: 36
Joined: 21 Oct 2017, 20:49

Re: KRACK vulnerability

#16 Post by s0170071 » 08 Nov 2017, 08:45

I found a workaround for the % issue:
the lines in the webform that fail, e.g. the display line or the publish line in the controller settings need to be url encoded. If you use the https://www.urlencoder.org/ it works.

So if you want to enter the line

Code: Select all

bla.exe?x=1+dom.GetObject("%valname%").State(%value%)

use

Code: Select all

bla.exe%3Fx%3D1%2Bdom.GetObject%28%22%25valname%25%22%29.State%28%25value%25%29
instead.

update:
If you're not afraid of some hacking go to WebServer.ino and replace anything like

Code: Select all

 reply += F("<form  method='post' ><table>");

with

Code: Select all

 reply += F("<form  method='post' enctype='multipart/form-data'><table>");
That fixes the issue for now. Further tests pending...

BertB
Normal user
Posts: 1049
Joined: 25 Apr 2015, 14:39

Re: KRACK vulnerability

#17 Post by BertB » 03 Dec 2017, 15:58

s0170071 wrote: 21 Oct 2017, 21:44 Hi all,

I just tried the new 2.4.0rc2 Arduino library as it has the latest WPA2 "Krack" vulnerability fixed.
https://github.com/esp8266/Arduino/rele ... /2.4.0-rc2
Good news: compiles and seems to run. Fast as lighning :D :D :D They changed the TCP acknowledge behaviour which makes the ESP considerably more responsive.


Issue:
-has some stray characters in the web interface. E.g. 65a 1b2 1ac on the main page right above "system info". A "48" above "powered by..." and a "0" below. See attachment.
-It does restart /crash after an hour or so.

Any Ideas (other than waiting for the final 2.4.0) ? Remember: it is really much faster than 2.3.0 and definately worth a try.
How can I get this in the Arduino IDE?

Post Reply

Who is online

Users browsing this forum: No registered users and 44 guests