When using the widget lock as a locker, an attacker can gain access to the file-system by selecting cashew->settings->add (image). Once the file selection dialog box opens that attack can see all the images on the system. As far as I could check, the attacker cannot access binaries or documents (But this is a possible attack vector). - Gilboa Reproducible: Always Steps to Reproduce: 1. Configure KDE to use the widget lock. 2. Lock the machine. 3. Cashew->settings->add.
Setting severity to critical, because this security issue makes the widget locker totally unusable.
Furthermore it is possible to "add widgets" on the locker and also download them through GHNS. Someone simply has to create a malicious script, upload it to kde-look.org, install it on the locker -> bang. I think the best solution would be to completely disable settings while the screen is locked. Configuration should be done through the KCM.
Sorry for the quick update: My assumption was wrong. Seems like only particular widgets can be added (but (de)installation through GHNS works). Tried e.g. to add "plasmacon" or "QML application launcher", which did not work. BTW.: It is possible to erase the filters (*.png, *.jpeg, ...), then all files can be browsed. Furthermore files can be renamed/deleted! And that is quite severe.
But the fact whether a plasmoid is safe for the locker screen is something the plasmoid itself declares, so this does not block your attack vector from comment #2.
Created attachment 78413 [details] patch to completely disable the plasma-overlay locker feature Here's a patch, as non-invasive as possible, that disables this feature completely.
Looking at the code, this only disables the widget locker during runtime without disabling it in the KCM. I assume this is a stop-gap solution?
(In reply to comment #6) > Looking at the code, this only disables the widget locker during runtime > without disabling it in the KCM. I assume this is a stop-gap solution? Well, it * "greys out" the radiobutton in the KCM (making it unselectable), * disables build of the code, * makes the session server ignore the setting in the config file that would enable it. Since I don't know that much QML and did not have too much time, I decided on minimal modification. Just removing the entire radio button probably works as well.
... Must have looked at a small part of the patch. My mistake. - Gilboa
The fancy new widget screen lock is one of KDE's much-touted new features -- too bad it's completely unusable, because it gives filesystem access to anyone who should happen to walk by your supposedly "locked" computer. They just have to click the cashew, click Settings, click Open, and they have a file dialog. From there, they can delete files at will as the logged in user.
+1, it's ridiculous that this critical security bug has been getting basically no attention for over 5 months now! This "feature" is totally unusable as it stands because the security hole defeats its whole purpose. If you can't fix it, you have to remove it.
Kevin, I wonder if the Fedora KDE team can somehow get in touch with someone @KDE and point out the severity of this issue. As it stands, this bug report is going nowhere. - Gilboa
The "problem" with all the new screen locker bugs is that they are reported to the plasma-bugs mailing list, which is not monitored by screen locker developers.
The problem is, You have to "lock" the configuration lock screen. On the lock screen, you go cashew>lock screen, and most of the options disapear, except for "Configure Widgets" and "unlock screen". When you click "Configure Widgets" it then asks for the password, and the configuration is unlocked, This is a usability issue. My suggestion to the developers is change the "Lock Screen" to "Lock Configuration", and add a warning whenever it's unlocked, similar to the capslock warning, and whenever it's unlocked make the cashew menu appear each time the screen is locked. perhaps it should also be locked by default.
I always knew that cashew was evil.. It should have been removed when KDE4 first started..
Note that you can also from the settings->wallpaper->slideshow->add directory create a new directory as the user; it must be called 'New Folder' (because it doesn't let you type), you can however paste into the filename!
adding widgets requires authentication; if you add widgets which allow exporing files on your system well .. yeah.
Aaron : this is incorrect, this is NOT about adding widgets This is the standard things like setting the wallpaper that lets you do this; this doesn't require auth.
Aaron, You're incorrect. Please execute the following steps: 1. Select Desktop widgets as screen locker. 2. Lock the screen. 3. Click on the Cashew. 4. Select "Settings". 5. When the Wallpaper selection opens, click "Open". 6. Start browsing the machine file system as the logged in user (I managed to connected to remote shares that used autofs, nfs and smb). At a minimum, this allows for a unauthenticated user to view local files on the local machine. I would suggest that as a stop-gate solution, a password lock will be added to the Cashew. Reopening the bug. - Gilboa
Gilboa, which version of KDE are you using? With 4.11.2 in order to get to the wallpaper setting you have to click "Configure Widgets" first which prompts for the password.
Nick; for me on 4.11.3 on FC20 I get the 'settings' button without needing a password. I think there are actually multiple problems (possibly separate bugs?): 1) Some of the widgets you can add are hopelessly insecure 2) For some of us the 'settings' button is visible without password 3) Some of the wallpaper items have not immediately obvious security issues - so even if you can't change them you can still do things 3a) 'mandelbrot' in particular there is a right click menu allowing you to save the mandelbrot and the settings. 3b) 'wallpaper of the day' also has a save option. Now OK Aaron reckons #1 is a user problem (as per comment 16) - I disagree but 2,3 is a separate issue.
@Nick: 4.11.3. - Gilboa
There might be some misunderstanding here. This was already mentioned in comment #13, but I'll repeat. After you enable Plasma locker you also have to start it (that is, lock your system) and use Cashew to lock widgets. Once you do this you'll be asked to enter your password both to add widgets and to change background. That's definitely a usability issue. The correct behaviour is not to save locked/unlocked state between screen locks, but to reset it to locked each time the screen is locked.
P.S. KDE 4.11.5 here.
At least on 4.12.3 (Fedora-current) I get *no* password prompt when adding and removing widgets and/or when trying to change wallpaper (which lets an unauthenticated browse files on the host machine or even open protected images - by selecting them as wallpaper). The password prompt appears when you try and unlock the screen. - Gilboa
Gilboa, have you locked the widgets? Here is how. First, you lock your session. Then click the Cashew and chose “Lock Screen” there. After this you'll have only two items in the Cashew menu, and both require your password.
Kirill, Widgets are locked on my desktop. No way to "lock widgets" inside the screen locker. Even if I lock the screen (using the Cashew) I can still access the settings, and from there, access all bitmaps on the machine. Which distribution are you using? They possibly carry some patch for this issue. - GIlboa
Gilboa, I'm using NixOS, and no, they have almost vanilla KDE. I can't see any patches related to this issue. I'll try to see if this happens to me in KDE 4.12. FTR, here is how the lockscreen menu looks for me: http://postimg.org/image/aeyyrqzpv/.
What happens if you click on the settings Cashew? - Gilboa
If I click “Settings” in this menu it lets me choose wallpaper.
Including a file dialog? There you have your security issue then.
Kevin, you are perfectly right! However, if you read my comment 22 and then look at the screenshot in comment 27, you will see the button labeled “Settings”, which you didn't fail to notice previously. But right below it there is the button “Lock Screen”—the one I was talking about. If you click it, the whole menu transforms, and you no longer can click the “Settings” button to bring up the file browser, until you click the “Configure Widgets” button, which will require you to authenticate. And I even have a screenshot for you: http://postimg.org/image/wlhus0gc5/.
Kirill, Seems that NixOS behaves differently once you "lock the screen". I'll check if they carry some type of patch compared to Fedora's RPMs. - Gilboa
*** Bug 330602 has been marked as a duplicate of this bug. ***
in order to change wallpaper or add widgets, it's necessary to put the password beforehand. If this on some circumstances doesn't happen, that's the actual bug (which i can't reproduce) It is perhaps possible to add widgets that are not secure, but that is a problem of the user. Considered that this is EOL code, no further modifications will be done, unless a way to invoke the wallpaper selection or add widgets without prior authentication is found.
(In reply to Marco Martin from comment #34) > in order to change wallpaper or add widgets, it's necessary to put the > password beforehand. If this on some circumstances doesn't happen, that's > the actual bug (which i can't reproduce) > It is perhaps possible to add widgets that are not secure, but that is a > problem of the user. > Considered that this is EOL code, no further modifications will be done, > unless a way to invoke the wallpaper selection or add widgets without prior > authentication is found. I can still reproduce this identically to my comment 20; on Fedora 21 which has kde-workspace-4.11.14-3. As previously stated; the 'configure widgets' item does need a password, however the 'settings' item does not, and that item has access to file dialogs on a number of the widgets.
The fact that 'settings' is behind 'configure widgets' which you said does indeed prompt for the password makes this a non-issue since you still need the password to even get to the menu with 'settings'. You've already entered your password for 'configure widgets' it's pointless to need to enter it again.
(In reply to Nick from comment #36) > The fact that 'settings' is behind 'configure widgets' which you said does > indeed prompt for the password makes this a non-issue since you still need > the password to even get to the menu with 'settings'. You've already entered > your password for 'configure widgets' it's pointless to need to enter it > again. Except it isn't; see this photo I just took: https://lh6.googleusercontent.com/-64NAfTTYoBM/VMaQE32d_wI/AAAAAAAAE_E/uFOA-lY3cdo/w607-h809-no/IMG_20150126_190345.jpg see - the 'settings' is a separate item in the menu, and I can click that item without having clicked 'Configure Widgets'.
That's very strange. It should not be there. I'm guessing this may be a Fedora patch or config issue.