New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Etcher should not fake a system password prompt #3321
Comments
See also #3309 |
From the #3309 link I also found #2975 and #3107 which are related. Based on this comment from the author of #3107, should we leave this issue open and continue tracking this problem through here? |
Etcher never sees the password, we use etcher/lib/shared/catalina-sudo/sudo.ts Line 34 in cc08ac9
Etcher never sees your password.
Please read the other issues, this no longer works for writing to
How ? I had a quick look at rpi-imager, it uses |
I don't understand how these requests are being closed with no native function in place! Why do the end users have to find a way to use your application, no other macOS application you have to either run as root via terminal or logout/switch user to an admin account to run the application? Why is admin privileges needed to create a bootable usb anyway? |
Because Etcher needs low-level raw block access to the disk, which (from a security point of view) is very different to writing files onto a filesystem. |
The Raspberry Pi Imager requires no such escalation shenanigans. It would be great to include the same method they use, but of course it could be some limitation of etcher being based on electron. Emulating a system prompt for a users password is a big no-no. |
@poohomar completely agree that there is a better way of doing it somewhere, we just haven't got the time to get on this specific issue. |
[gelbal] This issue has attached support thread https://jel.ly.fish/3ed2a7b3-19fd-43fd-992e-8bd97e86bbcf |
I'll throw my hat into this discussion as well, as the non-system password prompt actually made me a bit concerned that Etcher was doing something nefarious. Googled around a bit and found this issue. |
Same here, it did not make me a bit concerned though, it made me terribly concerned, which also lead me here. |
Locking the conversation as it's not our priority right now to beautify and/or normalize the dialogue to a system one, as it involves solving so many other parallel issues; we already made clear that we're more than welcome to receive PRs regarding the subject though, so if anybody feels like doing it, that would be awesome! |
Calling |
Just another vote for fixing this - downloaded and tried Etcher today and immediately went searching to see if this is spyware. Password prompts should always be from the system, period. An app-specific dialog asking for a password is basically a big sign that says "I'm here to steal your information and do something bad with it, just checking to see if you are foolish enough to fall for it". It seems like this wasn't done maliciously but, yeah, just another opinion here reiterating the point - this is a really bad and scary user experience. Etcher needs access, not my password. It's 2023, a lot more users know the difference these days. |
I totally agree with Bradleyoeabody. |
I find it puzzling that an application with such bad security practice and dubious privacy handling is often the recommended tool for flashing images. Well, I guess there often isn't a better alternative. |
I hope that a patch will be proposed to bring Etcher into line with good practice. Continuing to use Etcher as it works today is like living in the world of Dune, permanently wearing a heart valve on your chest: everything's fine as long as nobody pulls on it. Users can't be expected to check the source code for potential malicious changes every time they accept an update from Etcher. If we want to be consistent, we must uninstall Etcher on macOS as long as the application persists in asking the user for his password rather than requesting privileges to be raised from the system. This comment posted on #4026 states that the Raspberry Pi Imager application for macOS obtains the right to write blocks to a device directly from the OS, and not by collecting the password directly from the user.
|
This is a shame, and I would hope projects would reconsider this stance after the recent XZ compromise. I get there's no guarantees with FOSS but sure this attitude will reflect on Balenas commercial offerings as well. |
You’re right and it’s embarrassing but it’s not for lack of trying to resolve this. Digging into the problem the only way forward appears to be to refactor a huge chunk of Etcher into what Apple calls XPC services, which is not a project we can take on right now. |
Before flashing a device, Etcher shows what appears to be a system prompt asking for the user's password, but it is not in fact a system prompt: Etcher's own application is emulating a system prompt and capturing the password itself 👇
This tricks users, who think they are entering their password into a trusted system prompt, into forfeiting their password to an arbitrary userspace application who can do with it as it pleases, subverting the system's own mechanisms for escalating a process's privilege, so that the application can choose at it's own whim what to escalate, rather than the user.
This is similar to what Zoom's notoriously shady installer did to bypass escalation prompts, and even though not necessarily indicative of malicious practices, it's terrible practice and a complete betrayal of the user's trust, not to mention a possible malware vector.
Please, stop emulating system prompts and leverage the standard system mechanisms to implement process escalation. The RaspberryPi Imager app is similar in intent to Etcher and as far as I could tell, seems to be using the standard system mechanisms to escalate privilege when it's time to flash (as a matter of fact, it prompts for a much more granular and specific access than full-blown
sudo
), you should do the same.The text was updated successfully, but these errors were encountered: