Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

1Password CLI Vulnerability

codeberg.org

Post reply on HN
Print view View original

61–67 of 67 posts

Re: 1Password CLI Vulnerability

#61

Post by kachapopopow »

damaya1982 wrote: post #16
kachapopopow wrote: post #11

Earlier quoted context omitted.

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 exf…

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.

Re: 1Password CLI Vulnerability

#62

Post by kachapopopow »

hsbauauvhabzb wrote: post #25
kachapopopow wrote: post #11

Earlier quoted context omitted.

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.

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.

Re: 1Password CLI Vulnerability

#63

Post by zghst »

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.

Re: 1Password CLI Vulnerability

#64

Post by woadwarrior01 »

tredre3 wrote: post #58
woadwarrior01 wrote: post #17

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

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 elec…

It used to be a native app.

Re: 1Password CLI Vulnerability

#65

Post by macintux »

jen729w wrote: post #59
macintux wrote: post #56

Earlier quoted context omitted.

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.

Re: 1Password CLI Vulnerability

#67

Post by selinkocalar »

troad wrote: post #33

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 wher…

CLI tools have weaker security models than their GUI counterparts bc the assumption is usually that if you have terminal access, you already have elevated privileges.

But in shared environments or CI/CD pipelines, this doesn’t work. And the credential exposure through process lists is pretty bad.

Post reply on HN