KRACK vulnerability
Moderators: grovkillen, Stuntteam, TD-er
KRACK vulnerability
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 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.
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 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 (23.2 KiB) Viewed 11016 times
Re: KRACK vulnerability
In ESPEasy webserver.ino in the "sendWebPageChunkedData(String& log, String& data)" function there are a line: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.
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?
Re: KRACK vulnerability
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....
Update: I flashed all my ESPs with 2.4.0. core now. Let's see what's happening....
Re: KRACK vulnerability
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.
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.
Re: KRACK vulnerability
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.
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.
Re: KRACK vulnerability
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!
There must be something special going on here!
Re: KRACK vulnerability
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.
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.
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.
Re: KRACK vulnerability
I think that packet size is a plausible guess.. but how did you find 10 milliseconds?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.
Re: KRACK vulnerability
I found the 10 mseconds by trial and error.
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.
- I just updated it . The code above works for me now.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 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.
Re: KRACK vulnerability
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.
So lowering it to 1400-something may fix it, but it is an indication of the source of the problems.
Re: KRACK vulnerability
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.
However, I found another issue. Its the system %variables%. When I enter somthing like
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 ?
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.
However, I found another issue. Its the system %variables%. When I enter somthing like
Code: Select all
U: %uptime%
If you surround it with quotes "%" - the line stays. All other lines with sensor variables remain untouched.
Any ideas where to start searching ?
Re: KRACK vulnerability
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.
However, it crashes the ESP in the course.
Re: KRACK vulnerability
No problem with that.
HELLO
%uptime%
on OLED give this:
HELLO
%uptime%
on OLED give this:
- Attachments
-
- Display.jpg (11.51 KiB) Viewed 10660 times
Re: KRACK vulnerability
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
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
Re: KRACK vulnerability
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....
Re: KRACK vulnerability
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
use
instead.
update:
If you're not afraid of some hacking go to WebServer.ino and replace anything like
with
That fixes the issue for now. Further tests pending...
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
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>");
Re: KRACK vulnerability
How can I get this in the Arduino IDE?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 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.
Who is online
Users browsing this forum: Google [Bot] and 53 guests