Using 1Password 's `op` CLI tool exposes your secrets to other users(twitter.com)
twitter.com
Using 1Password 's `op` CLI tool exposes your secrets to other users
https://twitter.com/grhmc/status/1443037314817695744
6 comments
I'll never understand why "don't put nonpublic stuff in argv" is such a hard concept. I especially don't get why 1Password knew about this vulnerability and chose not to care about it.
They assume all their customers are on single person machines.
Of course under Unix and Linux even a single person machine can be running a lot of processes, including nefarious ones…
Of course under Unix and Linux even a single person machine can be running a lot of processes, including nefarious ones…
That's of course a wrong assumption of course but it's also not about persons necessarily. Eg lots of setups log the process list regularly to centralised monitoring.
This. 100%
For example, I remember a thread here on HN a while back about Zoom - which is unfortunately not optional for many people - frequently gobbling up an exhaustive list of running processes. Presumably this is to populate a list of apps you can share the screen off in a call, but we have no guarantees whatsoever that this information stays on the device. So all the user has to do is use that tool at the same time as Zoom looks at all processes and bang, they’ve got your data.
For example, I remember a thread here on HN a while back about Zoom - which is unfortunately not optional for many people - frequently gobbling up an exhaustive list of running processes. Presumably this is to populate a list of apps you can share the screen off in a call, but we have no guarantees whatsoever that this information stays on the device. So all the user has to do is use that tool at the same time as Zoom looks at all processes and bang, they’ve got your data.
Prefixing this with saying that I agree the UX on this is not great and could definitely be improved both from a usability standpoint and a security standpoint.
That said: The actual reality where someone gets their password stolen because they used 1Password's ClI tool seems pretty hard to run across. You have to have something running _at the exact moment_ when you're running this tool (and I imagine it shouldn't be running for very long) that also manages to harvest the entire set of running processes and their arguments. Said something then has to also transmit this information to a third-party server AND that third-party server has to be looking for this specific CLI tool in the hopes of catching it running.
Zoom is unlikely to manage to grab a list of processes at the same time that you're using this CLI tool (because it will be doing this on some internal timer or at the time when you are selecting something to share, and you have to be using it while using Zoom which should be a less-frequent occurrence due to generally paying attention to the call). And on top of that, if they even submit this information to their servers, I highly doubt they're going around deliberately scanning for passwords to maliciously use since they're a company focused on teleconferencing and not black hat activities.
And even beyond that this should still be more secure than a common alternative I've run into (and have done myself, because convenience was more important to me than 100% security at those jobs) where developers are just storing passwords and tokens in plain text in a bash/zsh rc file. That's a pretty easy target for a more realistic case of a module on something like NPM gaining some malicious code that checks some common files and patterns (e.g.: a line including export, PASSWORD, and =) and harvests that data to send to a malicious server.
And again, I'm not saying this is _good_, it's definitely not. I'm just saying that the case where this is actually exploited is pretty slim, bordering on not going to actually happen even if something just so happens to harvest that command running and sends it to their servers. Because it's much more likely that the thing harvesting that info isn't interested in stealing your password. There are much easier targets for malicious code to go after.
That said: The actual reality where someone gets their password stolen because they used 1Password's ClI tool seems pretty hard to run across. You have to have something running _at the exact moment_ when you're running this tool (and I imagine it shouldn't be running for very long) that also manages to harvest the entire set of running processes and their arguments. Said something then has to also transmit this information to a third-party server AND that third-party server has to be looking for this specific CLI tool in the hopes of catching it running.
Zoom is unlikely to manage to grab a list of processes at the same time that you're using this CLI tool (because it will be doing this on some internal timer or at the time when you are selecting something to share, and you have to be using it while using Zoom which should be a less-frequent occurrence due to generally paying attention to the call). And on top of that, if they even submit this information to their servers, I highly doubt they're going around deliberately scanning for passwords to maliciously use since they're a company focused on teleconferencing and not black hat activities.
And even beyond that this should still be more secure than a common alternative I've run into (and have done myself, because convenience was more important to me than 100% security at those jobs) where developers are just storing passwords and tokens in plain text in a bash/zsh rc file. That's a pretty easy target for a more realistic case of a module on something like NPM gaining some malicious code that checks some common files and patterns (e.g.: a line including export, PASSWORD, and =) and harvests that data to send to a malicious server.
And again, I'm not saying this is _good_, it's definitely not. I'm just saying that the case where this is actually exploited is pretty slim, bordering on not going to actually happen even if something just so happens to harvest that command running and sends it to their servers. Because it's much more likely that the thing harvesting that info isn't interested in stealing your password. There are much easier targets for malicious code to go after.
If your threat model involves me running somewhere custom code on your machine, but then me not being fast enough to grab argv, you may want to adjust your threat model. Because if I can't under those conditions (even just using shell shit, never mind some really tight c code, or something that hooks into the kernel), someone else can. What a seasoned security person will lean on here is threat models and level of access, but importantly, if I'm already running custom code on your machine as an attacker DO NOT assume I can't get at your argv.
I don’t understand why argv of other users’ processes needs to be public to non-root users in the first place, other than “that’s how it’s always been” - it’s clearly non-intuitive, so the mistake will naturally happen over and over again.
It needs to stay public by default because otherwise it would be a breaking change. If you're willing to break things and want to change it on your own system, it's easy: just mount /proc with the hidepid option.
I don't know what's going on over at 1Password, but some of their decisions/statements are really questionable. A month ago they dropped this[1] in response to the 1PW 8 beta feedback:
> I also wanted to respond to a specific part of @ShakataGaNai's original post about the multiple passwords. We've actually been recommending folks use the same password for each of their 1Password accounts. This might sound ironic given that the typical advice w.r.t. passwords is to use a unique password for everything. The difference is that your 1Password account password is intended to be the one password you remember, and so in theory, if you can only dedicate so much brain space to passwords, if you use only one password for all of your 1Password accounts, you'll be able to make that password stronger than if you have to remember multiple account passwords. So part of the new behavior encourages folks that direction.
More context can be found here[2].
[1] https://1password.community/discussion/comment/609753/#Comme...
[2] https://1password.community/discussion/122614/two-accounts-n...
> I also wanted to respond to a specific part of @ShakataGaNai's original post about the multiple passwords. We've actually been recommending folks use the same password for each of their 1Password accounts. This might sound ironic given that the typical advice w.r.t. passwords is to use a unique password for everything. The difference is that your 1Password account password is intended to be the one password you remember, and so in theory, if you can only dedicate so much brain space to passwords, if you use only one password for all of your 1Password accounts, you'll be able to make that password stronger than if you have to remember multiple account passwords. So part of the new behavior encourages folks that direction.
More context can be found here[2].
[1] https://1password.community/discussion/comment/609753/#Comme...
[2] https://1password.community/discussion/122614/two-accounts-n...
This comment is pretty misleading. You're making it sound like they advocated for using the same master password for all accounts, while the post you linked (#2) is about changing 1P (since 8.x) to NOT unlock all accounts with one master password/biometric. (1P<=7.x behavior)
The OP in that thread is complaining that he has to unlock each account separately with its own password. That response is a suggestion to mitigate password fatigue with multiple accounts and restore the same functionality as 1P7.
And as @gmemstr said, each 1Password Account also has a randomized "account key" mixed with your master password, making password stuffing attacks impossible. Your account key is given at signup and manually saved by the user. If you want to add a new device, you need to pull the key from an enrolled device or wherever you wrote it down.
The OP in that thread is complaining that he has to unlock each account separately with its own password. That response is a suggestion to mitigate password fatigue with multiple accounts and restore the same functionality as 1P7.
And as @gmemstr said, each 1Password Account also has a randomized "account key" mixed with your master password, making password stuffing attacks impossible. Your account key is given at signup and manually saved by the user. If you want to add a new device, you need to pull the key from an enrolled device or wherever you wrote it down.
To be fair to 1Pass, accounts also have a unique random account ID that is used in combination with email + password. But it does still kind of make you wonder...
That's... insane. So many breaches come from password stuffing attacks from leaked data. It doesn't matter how strong your password is if it's been compromised on another site.
Reply from 1Password: https://twitter.com/MrMichaelAbon/status/1443285349891862529
Checkout hidepid=2 mount option. https://linux-audit.com/linux-system-hardening-adding-hidepi... Some things can break (like pihole can't find the pidof FTL and such) but normally not an issue for most programs.
Well, that's a bit amateur hour. You either care about security or you don't. And here they clearly don't...which doesn't mean their products aren't otherwise secure, but does mean they're being created by a team that views security as, you know, one of several use cases.
Just got to hope they decided to prioritise the security use case for the things you care about, I guess?
Just got to hope they decided to prioritise the security use case for the things you care about, I guess?
I've been using 1Password for over 10 years and I had no idea that "op" existed until right now.
(( hangs head in shame ))
(( hangs head in shame ))
You can also get 2FA codes with it, although storing passwords and 2FAs in one system is probably bad practice.
It’s easy to miss. They’re not really advertising it.