DDoS triggered by a malicious hub may crash the client

[slrslr]

Application version AirDC++w 2.11.4 x86_64 Web UI version 2.11.5

Currently AirDC does not work for me ("Connecting to the server...") and creates ~32MB core dump .zst file. Are you interested to check the airdcppd .zst core dump file i have found on Linux Debian stable? If so, please let me know how to report it in private without publicly disclosing the dump file and possibly sensitive data in it (i would not be asking if i find contact on your site).

[maksis]

Instead of sending the zst file, have you tried using gdb as described in https://github.com/airdcpp-web/airdcpp-webclient/blob/master/.github/CONTRIBUTING.md#application-freezesdeadlocks ?

[slrslr]

Instead of sending the zst file, have you tried using gdb as described in https://github.com/airdcpp-web/airdcpp-webclient/blob/master/.github/CONTRIBUTING.md#application-freezesdeadlocks ?

Thanks, I have tried that commands:

$ pgrep airdcppd
[number]
gdb
attach [number]
thread apply all bt full

yet, before i manage to run all, the process is no longer running, so i have tried to:

cd $HOME/airdcpp-webclient
gdb airdcppd
set logging on
run airdcppd

Output: https://bin.disroot.org/?8e2842a03179e37b#CRUrFeL3bFtZWJqLYwKM15hVPyaRNjx4JWoCG88575Pj

Then I have downloaded same version from https://web-builds.airdcpp.net/stable/dbg_symbols/dbg_symbols_airdcpp_2.11.3_webui-2.11.4_64-bit_portable.tar.gz

tar -xzf dbg_symbols_airdcpp_2.11.3_webui-2.11.4_64-bit_portable.tar.gz cd .debug gdb airdcppd.debug set logging on run airdcppd.debug -> /bin/bash .../.debug/airdcppd.debug: cannot execute: Permission denied q chmod +x airdcppd.debug gdb airdcppd.debug set logging on run airdcppd.debug Program received signal SIGSEGV, Segmentation fault. 0x000000000048e225 in _start ()

what to do next please?

[maksis]

Then I have downloaded same version from https://web-builds.airdcpp.net/stable/dbg_symbols/dbg_symbols_airdcpp_2.11.3_webui-2.11.4_64-bit_portable.tar.gz

That is not a separate application, those are debugging symbols. You aren't supposed to execute them. Just run the application with gdb as you did earlier while the debugging symbols are in place so that the debugger can use those.

[slrslr]

run the application with gdb as you did earlier while the debugging symbols are in place

So i have moved .debug folder to $HOME/subdir/airdcpp-webclient and ran "gdb airdcppd" and "run airdcppd" with no crash 1st time, but second time this result:

--Type <RET> for more, q to quit, c to continue without paging--c

Thread 1396 "airdcppd" received signal SIGSEGV, Segmentation fault.
[Switching to LWP 4136961]
dcpp::BufferedSocket::threadSendData (this=0x0, this@entry=0x7fffe5d6b9f0) at /home/airdcpp/build/cache/x86_64/airdcpp-core/airdcpp/BufferedSocket.cpp:428
428     /home/airdcpp/build/cache/x86_64/airdcpp-core/airdcpp/BufferedSocket.cpp: No such file or directory.

Interesting is that it is using /home/airdcpp/ path which does not exist. I am launching gdb being in /home/user/subdir/airdcpp-webclient/

Full gdb.txt log output is here please kindly let me know.

[maksis]

thread apply all bt full is the relevant part that is needed

[slrslr]

thread apply all bt full is the relevant part that is needed

So i ran this before and after "run airdcppd" and the output/adb.txt seemed to show some new details (password is "ad") ...

[maksis]

How many hubs do you have open?

[slrslr]

How many hubs do you have open?

I am unsure how to discover it, but i have tried this: $ grep -c 'Connect="1"' ./config/Favorites.xml 38 Not sure how many are working and no hubs are connected since ADC no longer working, it crash as shown.

[maksis]

Are you sure that you aren't running out of memory? What kind of system is the app running on? I can't spot any reason for the crash from the logs.

[maksis]

You could try starting the application with no hubs connected (--no-auto-connect startup argument can be used). You can then open each hub individually to see what happens.

[slrslr]

(--no-auto-connect startup argument

Thank you, --no-autoconnect worked to do it. I have noticed that app always dump core several seconds after i connect this particular hub address: favorite-hub.net

[maksis]

Hmm, looks like it's the same hub that is also causing issues for another user: https://github.com/airdcpp/airdcpp-windows/issues/63#issuecomment-1528831424

It has something to do with the encoding

[maksis]

This isn't an encoding issue after all. The hub is being used to DDoS a Russian web site in a way that they send about 150 connection request per second (!) to the client asking the client to connect to the address of that specific site. AirDC++ (and most likely every other DC clients as well) can't throttle or even report such abuse. That's way too many connection requests for the client to make so it's no wonder that it may also crash the app as it hogs all system resources.

[slrslr]

Thank you for the fix and release new 2.12.0. When i connect this malicious hub "favorite-hub.net" under ADC 2.12.0, will i be still contributing to DDoS (only in the way that will not crash ADC) or it is entirely eliminated, so i can try to use the hub again without me DDoSing or wasting significant computer resources in relation to DDoS attempt?

[maksis]

I noticed that the hub had stopped the attack a while ago. The client will also report if it detects a similar attack in future. Personally I wouldn't want to stay in a hub that organizes DDoS attacks but it's your call.