Critical Denial of Service bugs in Discover

[Ben Cooksley]

On Fri, Feb 11, 2022 at 10:22 AM Fabian Vogt <fabian at ritter-vogt.de> wrote:

> 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.
>

Continues infinitely I assume?


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

Do we know if any distributions flipped that switch?


>
> Cheers,
> Fabian
>
>
Regards,
Ben
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/plasma-devel/attachments/20220212/51d34be1/attachment.htm>