Time  Nick     Message
02:09 mikyra   Hello together. I am new to this wohle IRC stuff so maybe I am asking silly questions. But are there by chance any minetest developers around?
02:14 mikyra   Well doesn't seem so. Not sure if messages will be queued to be delivered later by this wohle IRC stuff, so I will try to make things as short as possible, just in case I have to type everthing again.
02:16 calcul0n this is thepace for minetest devs mikyra
02:17 calcul0n but they are not always here, so just ask your question and stay around, someone will answer later eventually
02:17 calcul0n *the place
02:19 mikyra   The reason I was trying to get in contact is, that I am quite sure there is a more or less severe bug in the low-level network protocol. The "spec" in src/network/connection.h was very dry in places so was digging around the sources to check corner cases that weren't quite clear.
02:20 mikyra   Especially handling Reliable wrapped Split packes was such a case leading to my point.
02:24 mikyra   It turned out there is a problem with reliebale packets stored as IncomingSplitPackets. As they are marked reliable they will never be cleared out by the timout run on the ConnectionSendThread but just hang on for ever.
02:28 mikyra   This wouldn't be as bad as it seems, if verification of incoming split packets were not very lax to say the least. non-reliable Split packets via split sequence number beolonging to an IncomingSplitPacket marked as reliable will happily get buffered with just a warning showing up, but no further means taken.
02:34 mikyra   Thus making it possible to just sending the first packet of split packet wrapped as reliable packet with all other packets belonging to the this split packet not wrapped as reliable packet, preventing an "early" rollover over relibale packet sequence numbers.
02:40 mikyra   This means a malicous client may flood buffers using the following strategy. Send one reliable wrapped split packet marking it as the first of a sequence of up to 2^16 following split packets. Followed by named split packets sent unwrapped - i.e. not incrementing the reliable-packet sequence number counter.
02:41 mikyra   Rinse and repeat leads up to a theoretical total of 2^16 * 2^16 * max_packetsize (currently 1500 if I remember correctly) of memory consumed without the low-level network code ever taking notice.
02:43 mikyra   What makes things even worse is the fact that said attack can even be mounted without ever having completed connection setup.
02:45 mikyra   ack-ing SEET_PEER_ID and setting the ones own peer id is enough to get startet. Thus any server, even one requiring password login is prey to this attack.
02:51 mikyra   I quick hacked a proof of concept to verify the problem is not only theoretical and was able to flood the 12G of my testmachine leading to the well feared continiously-swapping syndrome in less then a few minutes. Not even scratching the theoretical limit of about 6 Terrabyte that could be flooded with the given strategy bevor reliable-packet sequencenumber rollover occurs.
02:54 mikyra   IMHO this problem should be fixed.
02:57 mikyra   I was not sure if it is a good idea to publically post the report on the issue tracker over at github, before the problem is fixed. So I decided to post it here.
02:58 mikyra   Hope someone takes it up. Best regards. ;)
15:35 VanessaE ugh, formspec imagine scaling looks like ass in 5.0.x :(
15:36 VanessaE looks like nearest neighbor instead of at least linear or bicubic
15:38 VanessaE ah there we go.  forgot to carry my config over :P