Bug 1221733

Summary: VUL-0: Possible unauthenticated code inclusion via themes in plasma 6
Product: [openSUSE] openSUSE Tumbleweed Reporter: William Brown <william.brown>
Component: SecurityAssignee: Security Team bot <security-team>
Status: NEW --- QA Contact: E-mail List <qa-bugs>
Severity: Normal    
Priority: P3 - Medium CC: filippo.bonazzi, fvogt, igorpadua, lbeltrame, opensuse-kde-bugs, security-team, sfalken, wstephenson
Version: Current   
Target Milestone: ---   
Hardware: Other   
OS: Other   
Whiteboard:
Found By: --- Services Priority:
Business Priority: Blocker: ---
Marketing QA Status: --- IT Deployment: ---

Description William Brown 2024-03-20 01:52:59 UTC
Community discussions and reports led me to https://www.reddit.com/r/openSUSE/comments/1biunsl/hacked_installed_a_global_theme_it_erased_all_my/ 

This appears to indicate that themes can include unauthenticated arbitrary code that is executed on install with the permissions of the user.
Comment 1 Fabian Vogt 2024-03-20 09:53:13 UTC
Plasmoids have the intentional ability to run executables. The analysis on the reddit thread shows that this was a genuine bug in a theme, not malicious intent. The theme was installed with explicit user interaction.

The offending theme has been removed and there is discussion happening upstream how to address this on any level.

Is there anything we should do from a downstream PoV until the upstream discussion has a result? We could add (another) warning dialog or disable the functionality to download third-party content by default, but that comes with other drawbacks.
Comment 2 William Brown 2024-03-21 02:28:03 UTC
(In reply to Fabian Vogt from comment #1)
> Plasmoids have the intentional ability to run executables. The analysis on
> the reddit thread shows that this was a genuine bug in a theme, not
> malicious intent. The theme was installed with explicit user interaction.

However, if a module were to have malicious intent it clearly would be easy to submit.

> 
> The offending theme has been removed and there is discussion happening
> upstream how to address this on any level.
> 
> Is there anything we should do from a downstream PoV until the upstream
> discussion has a result? We could add (another) warning dialog or disable
> the functionality to download third-party content by default, but that comes
> with other drawbacks.

I would advise that disabling the feature would be the best course of action until a concrete solution is provided in the upstream and project that can prevent this kind of potential exploit. However, I'm not part of the security team, so I will leave it to them to comment on their preference.
Comment 3 Filippo Bonazzi 2024-03-21 06:43:42 UTC
This is a reminder how easy it is to damage the user without ever crossing a privilege boundary. Even knowing that SDDM itself has issues (bug 1217188), I don't think this is related in any way. This is just KDE allowing the user to curl | bash a script that contains a rm -Rf call. Looks like this one was not malicious, but it just as easily could have.

The users of KDE need to be made awawre that this is an intentional choice by their DE, that this stuff has not been and cannot be audited, and that they are entirely on their own.

There is also https://blog.davidedmundson.co.uk/blog/kde-store-content/ that sort of discusses the issue.

If we want to take a stand on this, we can disable the functionality entirely on openSUSE (I would personally recommend it). This is a choice for the openSUSE KDE people to take though, since from security POV no privilege boundary has been crossed and things are working as expected.