etcher

etcher copied to clipboard

• Etcher version: All since commit 9b82891abb86fc27c3df531fa6e1086192de4f03 from @zvin
• Operating system and architecture: macOS (but possibly Linux as well, I don't it on desktop platforms to validate this)
• Image flashed: Does not apply
• Do you see any meaningful error information in the DevTools? Does not apply

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 👇

const result = app.displayDialog('balenaEtcher needs privileged access in order to flash disks.\n\nType your password to allow this.', {
  defaultAnswer: '',
  withIcon: 'caution',
  buttons: ['Cancel', 'Ok'],
  defaultButton: 'Ok',
  hiddenAnswer: true,
})

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.

See also #3309

From the #3309 link I also found https://github.com/balena-io/etcher/issues/2975 and https://github.com/balena-io/etcher/issues/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 sudo --askpass. The only code that "sees" the password is https://github.com/balena-io/etcher/blob/master/lib/shared/catalina-sudo/sudo-askpass.osascript.js , it is invoked by sudo ( https://github.com/balena-io/etcher/blob/cc08ac9236fad0e98700ab403726116122b821c6/lib/shared/catalina-sudo/sudo.ts#L34 ) and is not part of etcher itself. Etcher never sees your password.

Please, stop emulating system prompts and leverage the standard system mechanisms to implement process escalation.

Please read the other issues, this no longer works for writing to /dev/disk* starting from Catalina.

not to mention a possible malware vector.

How ?

I had a quick look at rpi-imager, it uses authopen, this could probably work for etcher too but requires some native code https://github.com/raspberrypi/rpi-imager/blob/qml/mac/macfile.cpp#L25 . Pull requests are welcome.

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?

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. https://github.com/raspberrypi/rpi-imager

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. PRs are welcome though, so if anyone of you wants to give it a try, as this is an open-source project, feel free to! :)

[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 sudo on a Mac is the wrong thing to do. My use account type is "standard" and you need to become an "administrator" to access the low-level disk device. As others have mentioned, the RaspberryPi Imager manages this feat. You don't need to become root do do it, you just need to ask the right question.

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 am here just because I found very strange that a program ask for my password, and not ask the system for access. I will try to see if there is an alternative (ie another program that do not ask my password, but rather ask access to the system).

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 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.

Alternatively, download the Raspberry Pi Imager from https://www.raspberrypi.com/software/ - it manages to ask for an admin username/password so it must be possible.

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!

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.