View Issue Details

IDProjectCategoryView StatusLast Update
0004924unrealircdpublic2018-12-09 09:47
ReporteracidvegasAssigned Tosyzop 
PriorityhighSeveritytrivialReproducibilitysometimes
Status resolvedResolutionfixed 
Product Version4.0.11 
Target VersionFixed in Version4.0.12 
Summary0004924: Remote MOTD requests causing netsplits
DescriptionAny server with a few links set up that have the default sendq listed on the documentation wiki (sendq 5M;) is vulnerable to an attack. Just about 20 clones all making multiple remote motd requests at such a speed (there is NO motd request throttle btw) can cause a netsplit on all of the links easily. One could increase the sendq but it never needs to be that high. I think the option to disable/enable remote motd and rules requests should a part of the config.

I managed to fix the problem temp by increasing the sendq and adding the following into my config:
tld {
    mask *@*;
    motd remote.motd;
    rules remote.motd;
    options { remote; };
};


remote.motd is a single line file that says that remote requests have been disabled.
Steps To ReproduceMost people follow the Link Tutorial guide on the documentation page and have only 5m sendq for link servers.

Create a hub with a few links and use a bunch of clones to spam /motd <link server name> over and over across all the links
TagsNo tags attached.
3rd party modules

Activities

syzop

2017-04-04 07:23

administrator   ~0019732

Last edited: 2017-04-04 07:24

View 2 revisions

We could (and should) lag users up when they request a remote MOTD. This so they can only request a remote MOTD once per 8 seconds or so. I'll check in something for that.

Another option would be to disable remote MOTD requests by default. Depends on how serious it is. We did this approach for remote-server support for /CREDITS and /INFO because the feature was rarely used and this output is not useful for users.

I'm surprised you are saying it only takes 20 clones to beat a 5M server sendq, though.
If your MOTD is 4kb then with 20 clones it would mean the server links can't sustain 2*40 = 80kb/s. Though with burst you can have tenfold at start (but only the first second), so 800kb/s, but the sendq would absorb that. Clones can reconnect to keep the burst speed but throttling would kick in after they do it 3 times in default configuration.

So I wonder if I'm missing something: Is your MOTD a lot bigger? Or do you have slow uplinks? All possible..

acidvegas

2017-04-04 08:10

reporter   ~0019734

Yeah I have quite a large motd, and a lot of servers sometimes do aswell, I forgot to mention that.

syzop

2017-04-07 20:05

administrator   ~0019735

Sounds like lagging up the user should suffice. Then they can do only one request per 10 seconds. So a tenfold decrease.
Even with a 10k motd and 100 clones that will only give a peak of 1MB -- from which it has 10 seconds to recover, so 100KB/s.

I could also have a look at just refusing MOTD responses when the sendq is at a certain percentage. That may be useful for other commands as well.

syzop

2017-04-07 20:07

administrator   ~0019736

I've done the former, since that's pretty much a one liner (the rest was just re-indenting):
https://github.com/unrealircd/unrealircd/commit/ee9f8441bc6cda5d277b4913ec07e8abeb3ffa2b

syzop

2018-12-09 09:47

administrator   ~0020397

I'm marking it as fixed in 4.0.12, the version containing the (first) fix. With a "normal motd" and sufficient sendq I would expect this to be sufficient, although I must admit that I did not test.

Issue History

Date Modified Username Field Change
2017-04-04 02:34 acidvegas New Issue
2017-04-04 07:23 syzop Note Added: 0019732
2017-04-04 07:24 syzop Note Edited: 0019732 View Revisions
2017-04-04 07:24 syzop View Status public => private
2017-04-04 07:26 syzop Assigned To => syzop
2017-04-04 07:26 syzop Status new => feedback
2017-04-04 08:10 acidvegas Note Added: 0019734
2017-04-07 20:05 syzop Note Added: 0019735
2017-04-07 20:07 syzop Note Added: 0019736
2017-04-07 20:07 syzop Status feedback => acknowledged
2018-12-09 09:45 syzop View Status private => public
2018-12-09 09:47 syzop Status acknowledged => resolved
2018-12-09 09:47 syzop Resolution open => fixed
2018-12-09 09:47 syzop Fixed in Version => 4.0.12
2018-12-09 09:47 syzop Note Added: 0020397