Critical Denial of Service bugs in Discover

[Fabian Vogt]

Moin,

Am Sonntag, 6. Februar 2022, 21:54:13 CET schrieb Fabian Vogt:
> Am Sonntag, 6. Februar 2022, 19:27:11 CET schrieb Ben Cooksley:
> > On Sun, Feb 6, 2022 at 1:07 PM Fabian Vogt <fabian at ritter-vogt.de> wrote:
> > > The first URL is used by kfontinst.knsrc from plasma-workspace:
> > > ProvidersUrl=https://distribute.kde.org/khotnewstuff/fonts-providers.xml
> > >
> > > The second URL is used by multiple knsrc files in my VM:
> > > aurorae.knsrc:ProvidersUrl=https://download.kde.org/ocs/providers.xml
> > > comic.knsrc:ProvidersUrl=https://download.kde.org/ocs/providers.xml
> > > kwineffect.knsrc:ProvidersUrl=https://download.kde.org/ocs/providers.xml
> > > kwinscripts.knsrc:ProvidersUrl=https://download.kde.org/ocs/providers.xml
> > > kwinswitcher.knsrc:ProvidersUrl=https://download.kde.org/ocs/providers.xml
> > > wallpaperplugin.knsrc:ProvidersUrl=
> > > https://download.kde.org/ocs/providers.xml
> > 
> > This makes me incredibly sad. We had a push to eliminate all usage of the
> > legacy download.kde.org endpoint many years ago...
> > I have now resolved the majority of these - if distributions could please
> > pick up those patches that would be appreciated.
> > 
> > Please note that I have now terminated the support on the server that was
> > making these legacy endpoints work, so those patches are necessary to
> > restore functionality.
> ...
> It's also possible that the requests aren't actually caused by Discover at all,
> but just something which imitates it in a DDoS attack. In that case we couldn't
> do anything on the client-side anyway. I don't think this is very likely, but
> until the issue was reproduced with disover it's a possibility.

I think I have a plausible explanation for what could've caused this.
While testing a MR for the notifier, I noticed odd behaviour: It always ran
plasma-discover-update twice!
https://invent.kde.org/plasma/discover/-/merge_requests/254#note_394584

The reason for that is that after the update process finishes, the notifier
realizes that it's idle again and if updates are available, it will immediately
trigger another update after the 15min idle time. Now here's the catch: If the
system has already been idle for >=15min (which is very likely at that point),
the idle timeout will immediately fire! This process repeats unlimited and
without delay, until the system is no longer idle or there aren't updates
available anymore. Here I have plasma-discover-update running approx. every
second, which amounts to ~4 req/s to download.kde.org.

This is mostly mitigated by the introduction of the 3h delay between updates
by d607e0c6f9, but not entirely. The check is only effective after the second
iteration, which is what I observed in my testing. (One of the commits in my MR
should address that as well.)

One of the conditions for running into this bug is that after the automatic
updater ran, there still have to be updates available to trigger the next run.
Initially I thought that this can mostly happen if updates fail to download or
install, this is unfortunately not true. The notifier by default counts all
available updates, but the updater only installs offline updates. So if there
is even a single non-offline update available, the loop continues.

So this probably affected a lot of users who enabled automatic installation of
updates :-/

Cheers,
Fabian