[Security flaw] Greenshot opens Chromewindow with system privileges on windows-loginscreen

Description

There is a serious security-flaw in the latest Windows version 1.2.10.6 wich - when you install it remotely on bootup by a software deployment tool - opens up a chrome (default browser) window without a logged in user on the login screen.

Because there is no logged in user, it is a process with system privileges, so you can browse all files on the computer.
This was not the case with 1.2.9.129.

Please fix this ASAP.

Environment

Windows 10 with Chrome as default browser. Greenshot deployed automatically by OPSI on bootup.

Activity

Show:
Robin Krom
October 12, 2017, 9:43 AM
Edited

This is not new, this has already been like this for a long time. More information can be found here: https://getgreenshot.org/faq/how-can-i-avoid-greenshot-opening-a-browser-window-at-the-end-of-the-installation-process/

We do make it possible to deploy Greenshot without the installer, see here: https://getgreenshot.org/faq/in-which-cases-should-i-use-the-zip-package-instead-of-the-installer/
Also interesting: https://getgreenshot.org/faq/what-is-the-best-way-to-control-greenshots-configuration-at-install-time/

You will have to invest time in this yourself, we cannot support all deployment modes for free.

Robin Krom
October 12, 2017, 10:06 AM

If we only had the installer, I would agree that we need a different solution for deploying Greenshot.
But the installer works as designed, so this is not a bug and I will close this with "Won't do"

We also assume (as we don't provide a solution) that companies look for the best solution fitting to their infrastructure / deployment service, and test their roll-out.

While most companies don't donate / spend / pay us for using Greenshot, they have this "it's free" mentality, we don't focus on deployment scenarios. They do create tickets in our JIRA, expecting a solution fast and mostly cost us a lot of time. This might not be the case here, I speak of "in general".

I advice you to read our FAQ's and all the information in there, if something is unclear or doesn't work as described I will be more than happy to give the missing information of fix the functionality.

Benjamin Kix
October 12, 2017, 10:27 AM

I do understand that you can't support all deployments without getting payed..
I'm totally fine with this and I appreciate that there are other installation options to circumvent that behavior.

But I must stress that this is still a serious security flaw. There should never be under any circumstances a process that allows user input before Login with system privileges.
It's not about fixing something for us (we already have a workaround). This is about fixing a real problem that can lead to a compromised system.

It should be really easy to fix this too. Just don't open the browser in the Installation process. Open it on first run by the User.
That should help your project too, because on a multiuser system your legit request to support the project would be shown to every user that uses your tool.

Please reconsider wisely.. once again: With this behavior anyone (without login!) stumbling over the browser after installation has full access to the system and therefore can do harm.

Assignee

Unassigned

Reporter

Benjamin Kix

Affects versions

Components

Priority

Critical

Labels

Configure