Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Server aborted on incorrect messages. #2052

Closed
o01eg opened this issue Mar 14, 2018 · 11 comments · Fixed by #2563
Closed

Server aborted on incorrect messages. #2052

o01eg opened this issue Mar 14, 2018 · 11 comments · Fixed by #2563
Labels
category:bug The Issue/PR describes or solves a perceived malfunction within the game. component:network status:resolved The Issue was resolved, either by answering properly or fixing the underlying bug.
Milestone

Comments

@o01eg
Copy link
Contributor

o01eg commented Mar 14, 2018

Environment

  • FreeOrion Version: My o01eg@62d0374 (based on f9c6da6 )
  • Operating System: Ubuntu Server 16.04.4
  • Fetched as
    • Compiled from source

Description

Server don't check message size so it possible to DoS it with incorrect message:

Core was generated by `/usr/lib/freeorion/freeoriond --resource-dir /usr/share/games/freeorion/default'.
Program terminated with signal SIGABRT, Aborted.
#0  0x00007fab20cf1428 in __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:54
54	../sysdeps/unix/sysv/linux/raise.c: No such file or directory.
(gdb) bt
#0  0x00007fab20cf1428 in __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:54
#1  0x00007fab20cf302a in __GI_abort () at abort.c:89
#2  0x00007fab2163484d in __gnu_cxx::__verbose_terminate_handler() () from /usr/lib/x86_64-linux-gnu/libstdc++.so.6
#3  0x00007fab216326b6 in ?? () from /usr/lib/x86_64-linux-gnu/libstdc++.so.6
#4  0x00007fab21632701 in std::terminate() () from /usr/lib/x86_64-linux-gnu/libstdc++.so.6
#5  0x00007fab21632919 in __cxa_throw () from /usr/lib/x86_64-linux-gnu/libstdc++.so.6
#6  0x00007fab21632ebc in operator new(unsigned long) () from /usr/lib/x86_64-linux-gnu/libstdc++.so.6
#7  0x00007fab21632f19 in operator new[](unsigned long) () from /usr/lib/x86_64-linux-gnu/libstdc++.so.6
#8  0x00007fab23914164 in Message::Resize (this=0x55c2744259c8, size=<optimized out>) at /home/o01eg/freeorion/network/Message.cpp:83
#9  0x000055c2724bf82b in PlayerConnection::HandleMessageHeaderRead (this=0x55c274425970, error=..., bytes_transferred=<optimized out>)
    at /home/o01eg/freeorion/network/ServerNetworking.cpp:339
...
(gdb) f 9
#9  0x000055c2724bf82b in PlayerConnection::HandleMessageHeaderRead (this=0x55c274425970, error=..., bytes_transferred=<optimized out>)
    at /home/o01eg/freeorion/network/ServerNetworking.cpp:339
339	            m_incoming_message.Resize(m_incoming_header_buffer[Message::Parts::SIZE]);
(gdb) p m_incoming_header_buffer
$1 = {_M_elems = {5, -1}}

Expected Result

Drop connection with wrong messages and log them in grepable (for fail2ban) way.

Steps to reproduce

S=<message size in bytes> ; H=`printf "%08x\n" ${S}` ; (echo -ne "\x03\x00\x00\x00`echo "\x${H:6:2}\x${H:4:2}\x${H:2:2}\x${H:0:2}"`"; cat /dev/urandom | head -c ${S} ) | nc <server ip> <port>
@o01eg
Copy link
Contributor Author

o01eg commented Mar 14, 2018

I'm going to restrict message by 10 MiB but not sure if it is not reachable in the real game. At least the server was successfully tested with 650 MiB messages in MPLobby state.

@geoffthemedio geoffthemedio added category:bug The Issue/PR describes or solves a perceived malfunction within the game. component:network labels Mar 14, 2018
@Vezzra Vezzra added this to the v0.4.8 (optional) milestone Mar 15, 2018
@adrianbroher
Copy link
Contributor

That's probably not easily fixable, as we send the whole game state (and the whole game history AFAIK?) every round. The proper fix would be delta updates. If somebody could check for a 1000 round game (or can I generate something like this by hand?) we could guestimate a maximum useful savegame size.

@adrianbroher
Copy link
Contributor

adrianbroher commented Jun 7, 2018

@geoff, @Vezzra, @Dilvish-fo any hints on how to generate a huge savegame?

@o01eg
Copy link
Contributor Author

o01eg commented Jun 7, 2018

@adrianbroher

That's probably not easily fixable, as we send the whole game state (and the whole game history AFAIK?) every round.

This issue is about messages sent from client to server not from server to client.

If somebody could check for a 1000 round game (or can I generate something like this by hand?) we could guestimate a maximum useful savegame size.

Game test #2050 could generate them.

@geoffthemedio
Copy link
Member

Start a game with 1000+ stars, 20+ AIs, high everything, and let it auto-cycle the turns for a while... Save files are 2 MB after 11 turns or so, and keep growing...

@Dilvish-fo
Copy link
Member

any hints on how to generate a huge savegame?

The way Geoff describes is the way to do it if it was really needed, but the turns can get to be really slow even with autocycle. From your later comment it sounds to me like it is not really needed to actually play out such a big game.

This issue is about messages sent from client to server not from server to client.

Seems to me that the message size from client to server will be just about entirely determined by number of ships + planets owned by the empire at the given point. I'd suggest Autoplay 2 AIs in a 200 system galaxy for 200-300 turns. Take the sum of both of their server-bound message sizes at that point, multiply by 25 (5000 max stars / 200 stars) and then probably add some extra safety factor.I expect you'd still be well under the 10MB limit you proposed.

@Vezzra
Copy link
Member

Vezzra commented Jun 8, 2018

No ideas beyond what @geoffthemedio and @Dilvish-fo already mentioned...

@geoffthemedio
Copy link
Member

Saves on later turns are bigger than the current universe state, since empires also remember previously-seen objects.

@Dilvish-fo
Copy link
Member

Saves on later turns are bigger than the current universe state, since empires also remember previously-seen objects.

Sure, but that aspect doesn't really have any effect on the size of the orders submission sent from the client to the server, which is what I'd expect to be the largest of the server-bound messages.

@Vezzra Vezzra modified the milestones: v0.4.8 (optional), post 0.4.8 Aug 31, 2018
@Vezzra
Copy link
Member

Vezzra commented Sep 22, 2019

@freeorion/developers, what's the status of this?

@o01eg
Copy link
Contributor Author

o01eg commented Sep 22, 2019

@Vezzra I think it better to set option network.server.client-message.size and set it to 0 (unrestricted) by default.
On the my Internet-available servers I uses 10 MiB restriction and didn't get issues with it.

@Vezzra Vezzra modified the milestones: Next Release, v0.4.9 Sep 22, 2019
@Vezzra Vezzra added the status:resolved The Issue was resolved, either by answering properly or fixing the underlying bug. label Oct 2, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
category:bug The Issue/PR describes or solves a perceived malfunction within the game. component:network status:resolved The Issue was resolved, either by answering properly or fixing the underlying bug.
Projects
None yet
Development

Successfully merging a pull request may close this issue.

5 participants