Bug 419310 - Kickoff (also maybe for alternative menus too): Security concerns
Summary: Kickoff (also maybe for alternative menus too): Security concerns
Status: RESOLVED FIXED
Alias: None
Product: plasmashell
Classification: Plasma
Component: Application Launcher (Kickoff) (show other bugs)
Version: master
Platform: Other Linux
: NOR normal
Target Milestone: 1.0
Assignee: David Edmundson
URL:
Keywords:
: 419308 (view as bug list)
Depends on:
Blocks:
 
Reported: 2020-03-27 19:59 UTC by Gabriel Fernandes
Modified: 2020-03-29 23:47 UTC (History)
2 users (show)

See Also:
Latest Commit:
Version Fixed In: 5.18.4


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Gabriel Fernandes 2020-03-27 19:59:08 UTC
Please, take a look at the post, it explains the problem and things it might cause
https://www.reddit.com/r/kde/comments/fpqbi2/krunner_and_kickoff_security_concerns/

I would like to suggest Kickoff (also alternatives) to only execute files from the PATH (when it says "run script"), not from recent files or file search
Comment 1 David Edmundson 2020-03-27 21:56:14 UTC
Please don't link social media sites. 

File a bug properly.
Comment 2 David Edmundson 2020-03-27 22:10:26 UTC
Edit: my reply was maybe a little curt.

I see now you are probably the original reporter, which helps.

In any case. Please do paste copy and paste inline. Partly for prosperity, and partly because I don't want to have to copy text from an image.. 


Also I'm not sure I understand from the information given.

I created a file called test.png. It was really .desktop file with an Exec line


I open in dolphin, it tries to open gwenview despite "file.png" showing the magic header as being ascii text.
Comment 3 Gabriel Fernandes 2020-03-27 22:17:21 UTC
Oh sorry. I just didn't want to duplicate myself, in this case triplicate (also another report for krunner product).

It doesn't work if the file have a common extension, as png, if you name it "file.png." for example, open the file to have it as a recent file when you search using kickoff or krunner, when you enter the file it will get executed.
Comment 4 David Edmundson 2020-03-27 22:29:51 UTC
*** Bug 419308 has been marked as a duplicate of this bug. ***
Comment 5 David Edmundson 2020-03-27 22:40:22 UTC
>open the file to have it as a recent file when you search using kickoff or krunner,

But then it's been already run? Unless the user does "open with" the first time.

I don't yet understand why it's different from the typical dolphin + executable desktop file case?  If anything it's more convoluted as the user has to open the file twice.
Comment 6 David Edmundson 2020-03-27 22:49:28 UTC
Fix itself is pretty straightforward: https://phabricator.kde.org/P566

Generally there's not too much we can do against the .desktop situation (without also breaking things), but in this case it maybe makes sense given we know the context is recent documents.
Comment 7 Gabriel Fernandes 2020-03-27 23:03:10 UTC
In dolphin we have 3 options.
1. You have a popup that asks you what you want to do (open or execute)
2. Set open as default, so always when you click an executable the file is opened with a default application (kate, let's say)
3. Execute without asking.

Let's say you have second option set in dolphin, so one time, you clicked the file, it just got open in the text editor, fine, secure.
If that file pops up in krunner/kickoff, it will only get executed, there's no the same safety mechanism dolphin has (the 2 first options).
This kinda deceives you, as you don't expect the different behavior (you are certain you won't execute any untrusted executable from dolphin because of the safest options, but you might be tricked by the launcher to execute something you opened once to inspect what's in there)
Comment 8 David Edmundson 2020-03-27 23:11:40 UTC
Ok, that's a reasnoble answer.

I'll land the above.
Comment 9 Gabriel Fernandes 2020-03-28 00:52:52 UTC
That's really good.

I'm afraid it's possible to suffer from the same effect through other runners.
It doesn't seem to be possible to execute a file from the "Desktop search" runner as it filters to show only truly images, audio etc.
But the "Locations" runner does execute the .desktop file
Comment 10 David Edmundson 2020-03-29 15:10:26 UTC
>But the "Locations" runner does execute the .desktop file

But that requires explicit user activity to get it in locations first, right?
Comment 11 David Edmundson 2020-03-29 15:13:16 UTC
Git commit 97bf7d777e56a451eb91731d9209fb1d55689957 by David Edmundson.
Committed on 29/03/2020 at 15:13.
Pushed by davidedmundson into branch 'Plasma/5.18'.

[runners/recentdocuments] disable executables or .desktop files

Summary:
It's possible to have a .desktop file in your recent documents list as
you were editing it. Either as a .desktop file or masquerading as
something else.

By default we would process the .desktop file like a .desktop file.

You do get a prompt if the .desktop file is not executable like in
dolphin.

Given we know from context that we're showing recent "Documents" we may
as well turn that behaviour off without risk of ill effects.

Test Plan:
Created .desktop file (masquerading as something else)
Had it in my recent documents after opening in another format
Loaded the file from krunner. It now opened in my text editor instead of running
the Exec line

Reviewers: #plasma, ngraham

Reviewed By: ngraham

Subscribers: ngraham, plasma-devel

Tags: #plasma

Differential Revision: https://phabricator.kde.org/D28369

M  +2    -1    runners/recentdocuments/recentdocuments.cpp

https://commits.kde.org/plasma-workspace/97bf7d777e56a451eb91731d9209fb1d55689957
Comment 12 Gabriel Fernandes 2020-03-29 17:33:35 UTC
>But that requires explicit user activity to get it in locations first, right?

Yes, the user has to enter the location. Much less likely to happen.
I just wanted to point out, even though it says open, in fact it executes the file: https://imgur.com/a/NHjKpuS