Summary: | PlasmaCore.DataSource "executable" engine arbitrary code execution via any QML file in backdoored wallpaper plugins, themes, etc. distributed via store.kde.org | ||
---|---|---|---|
Product: | [Plasma] plasmashell | Reporter: | Benjamin Flesch <benjaminflesch> |
Component: | general | Assignee: | Plasma Bugs List <plasma-bugs> |
Status: | CLOSED INTENTIONAL | ||
Severity: | normal | CC: | ad.liu.jin, info, kde, security |
Priority: | NOR | ||
Version: | 5.27.10 | ||
Target Milestone: | 1.0 | ||
Platform: | Other | ||
OS: | Linux | ||
Latest Commit: | Version Fixed In: | ||
Sentry Crash Report: |
Description
Benjamin Flesch
2024-01-20 22:57:39 UTC
Same as installing any program. (In reply to David Edmundson from comment #1) > Same as installing any program. Yeah, but it seems safe as it's only downloading a jpg file, not that it can also execute code . Does this only affect wallpaper plugins, applets, themes, window decorations, etc.? Or does it also affect wallpaper images, colors, yakuake skins, etc? The difference is that in former cases, in addition to QML, you can also upload C++ code, where anything is possible. So being able to do the same in QML doesn't change the attack surface. While in the latter cases, I do expect them to be just pictures and config files. I did build a proof-of-concept for the "wallpaper plugin" type, and did a survey of 10.000 themes from shop.kde.org which found ~10 packes with .exe files that show as virus on virustotal.com (these have been removed by plink), and various packages with .so library files, shell scripts (.sh) and python scripts. Currently to me it seems anything goes and the whole security theatre depends on the operations of plink, who - as I've shown - don't even scan the packages with conventional antivirus scanners. Another big problem is that the plasma dialogs all show "most recently uploaded" themes/plugins right at the top, so it's easy for an attacker to get initial infections. From my perspective, the QML surface & code execution capabilities of packages installed via the plasma store(s) should be severly limited on the plasma side. There should be two types of QML: trusted QML and untrusted QML. Trusted QML only for packages signed by the plasma devs. Untrusted QML for everyone. I'll try to find more security vulnerabilities in plasma to make the architects of the current thing reconsider their choices. Also the biggest security risk, a compromise of plink gmbh (a private company) and then a deployment of malicious updates for *all* themes at the same time will be installed via discover software center "plasma addons" section to many KDE users. Targeted attacks on KDE/plasma devs with the current design are also a realistic thing. Your concern is valid. But as I said, the store also contains C++ plugins in the same category, so the suggested change in this bug report alone doesn't really help at the moment. As you already pointed out, to improve the situation, we need radical changes in a lot of areas. Definitely not something to do at the moment, only a few weeks to 6.0 release. We can discuss the plan later, after the release. And the plan doesn't necessarily include removing this particular QML function, but may well be something radical like sandboxing user contents. What do you think about adding a warning, so users pay more attention installing plugins and check its sources? Just like you say, at the end of the day this concern is valid for any application which you install from everywhere, but here users (including myself) does not think that it may contain a executable as it's only a wallpaper plugin. Also I didn't understand whether installing a wallpaper could have a code execution capability or this only applies to plugins? |