RakNetDOS (!)

[8artek0v0]

RakNet DoS attack.

The problem lays in ACKs and NAKs system in function: ReliabilityLayer::HandleSocketReceiveFromConnectedPlayer

commit e97c4bb005ad5d98ceb04298e9921781720a1dca didn't fix it

Specially crafted packet can hang RakNet thread for quite a while or freeze it for good.

ReliabilityLayer.cpp

Line 736: for (i=0; i<incomingAcks.ranges.Size();i++) { ... ... Line 746: for (datagramNumber=incomingAcks.ranges[i].minIndex; datagramNumber >= incomingAcks.ranges[i].minIndex && datagramNumber <= incomingAcks.ranges[i].maxIndex; datagramNumber++) }

and

Line 818: for (i=0; i<incomingNAKs.ranges.Size();i++) { ... ... Line 831: for (messageNumber=incomingNAKs.ranges[i].minIndex; messageNumber >= incomingNAKs.ranges[i].minIndex && messageNumber <= incomingNAKs.ranges[i].maxIndex; messageNumber++) }

When ranges[i].minIndex = 0 and ranges[i].maxIndex = 0xFFFFFFFE then loop will be executed 4294967294 times. Which is a lot. What is more, a single packet can contain even 200 "ranges" or more. So loop at line 746 and 818 going to be executed 200 * 4294967294 = 858993458800 times, because ranges.Size() = 200; This can hang RakNet thread for a while, so no new incoming connections are going to be accepted and all peers already connected will timeout.

Special case: incomingNAKs.ranges[i].minIndex = 0 and incomingNAKs.ranges[i].maxIndex = 0xFFFFFFFF then loop at line 818 will never end.

In this case RakNet thread will be trapped in an endless loop.

[BigJoe01]

Hello, have any solution?

[ghost]

Картинка для привлечения внимания галкора (Kalcor)

[Luke1410]

Thanks for the report and analysis @8artek0v0 . We have it on our short term list to resolve it for good in SLikeNet (our fork of RakNet). I just committed the obvious fix for the endless loop case. And will leave a note here once we handled the other reported issue as well (internal case number SLNET-194 / SLNET-204).

[Luke1410]

Just to give a quick heads up: We are now working on this issue. We made several changes to the area and are currently testing/reviewing them to ensure this completely resolves this DOS attack vector.

If you need an urgent patch for this issue, feel free to get in touch by mail at info@slikesoft.com.

[Luke1410]

We are going to release an unplanned hotfix of SLikeNet due to this exploit (SLikeNet 0.1.2) and will also provide a pull request to RakNet (for those who are staying with RakNet). We are currently targeting a release on 2018-05-06. As stated in the previous commit, if you need an urgent fix, feel free to contact us by mail.

This exploit has the following CVSS score: base score: 7.5 temporal score: 7.2 (7.5 until SLikeNet 0.1.2 is released) overall score: 7.2 (7.5 until SLikeNet 0.1.2 is released) CVSS v3 vector: AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H/E:H/RL:O/RC:C

Since SLikeNet/RakNet are libraries, there's no CVSS environmental score (since that score heavily depends on how/where the library is utilized).

[Luke1410]

@8artek0v0 Thanks for the original report of this exploit. Due to lack of other means to contact you, adding this one as a comment here:

As stated above the upcoming SLikeNet release will contain a fix for your reported exploit. If you are fine with that, we'd mention you in the announcement messages which will be posted alongside the release. The statement will read: We'd like to thank the GitHub user 8artek0v0 for his report of the vulnerability in RakNet.

If you'd rather have a different name stated (f.e. another nick, or your real name) please let me know. You can also reply/discuss this by mail to info@slikesoft.com. Please note that unless you contact us, we won't add that note to the announcement mail in order to respect your privacy.

[Luke1410]

SLikeNet 0.1.2 which resolves the related cases (SLNET-194, SLNET-202) is available now on https://www.slikenet.com/ and on the GitHub project page: https://github.com/SLikeSoft/SLikeNet/releases/tag/v.0.1.2 .

Please note that we are currently in touch with facebook to coordinate the steps to make a fix for the issue available via a pull request. Therefore, we decided not to go ahead with this right now but will rather do so at a later time. If you have a project and rely on a fix, please get in touch with us by mail and we'll make the fix available to you in private ( info@slikesoft.com ).

[Luke1410]

Just a couple of small corrections to the initial report from @8artek0v0: The type is actually an uint_24 value which has a value range of 24-bit. The max range is therefore 0xFFFFFE resulting in the loop iterating up to 16.777.216 times (not 4.294.967.294 times). Technically the limit for the number of ranges capped at 2^16, so ultimately the loop could iterate 2^40 times in total. However, this is practically capped by the range package not exceeding the MTU-size (which usually is around 1k-1.5k at the time of writing this). So we are talking here much less than 2^40. 200 ranges however fit well within that MTU-size limit so that a loop count of 2^16*2^8 = 2^24 is what one should expect here to be a reasonable/practical upper limit.

As stated: This is just nitpicking to correct some facts. The essence of the report is completely valid.