Improve CLI login security, agent dameon, security issue!

I’m a bit concerned about how CLI login and session maintenance currently works. The docs say not to store the session token on disk due to unencrypted disk concerns. In many ways, storing it in the env has similar issues, as on a multi-user/tenant system you can’t really be sure that the person who has read access to that should. Also, accidental exposure of env is super easy. For more reasons you shouldn’t, I found this Why you shouldn't use ENV variables for secret data googling returns plenty of results, though. I would argue, in the current state of things, this is a reasonably serious security vulnerability in shared environments.

One solution to the env issue is to store the key in /run on Linux systems. I’m not certain if OS X and Windows offer any similar file systems that are automatically a ramdisk. There are places that a user has write access to create their own files that are readable only by them.

The is to simply store the session code in the system’s keyring. This has a problem of, what if you’re using Bitwarden as the system’s keyring? Or there isn’t one.

I’m not entirely certain how keyring’s unlock and stay unlocked, but I know that ssh, and GPG, both have agent daemon’s. That may mean that Bitwarden might also need to provide a bw-agent program that maintains the unlocked state. This in fact might be the best solution of all, and perhaps the desktop client could use it as well, so that both integrate into the same thing. This is probably the best solution, but I believe can, should also integrate with ASKPASS.

As another comment, passing the argument via an option is also insecure.

Further per security issue. Yes I could have reported this privately, but this is a very public API, certainly not a zero-day.

https://cwe.mitre.org/data/definitions/526.html
https://cwe.mitre.org/data/definitions/214.html

Hey Xeno,

Thanks for the thoughtful post. You bring up some interesting points. It’s totally true that the env and parameters of bw runs can be sniffed through ps or /proc. However, that’s why we’re using a session key rather than anything more permanent. If you have reason to think your session key has been compromised, simply log out and log back in to cycle it.

That being said, the solution suggested in the link you posted is pretty nifty. I think you already know the difficulty we’re facing doing something like this ourselves – we need to be cross-platform for Windows, Mac, and Linux. That doesn’t mean we can’t help enable other solutions, though…

It looks like the solution you linked just provides a file readable only by your user. What if we just allow the session variable to be passed in as a filepath to read, like we do with the passwordfile option?

1 Like

Yeah, I think the problem with env vars ultimately comes down to the fact that accidental exposure is super, super easy. Loading a file of any kind is probably fine, you could make it one ~/.config/bitwarden and require it to have 0400 permissions like ssh does. Obviously, that only applies to *nix systems. Obviously at that point you could autoload it, or allow the location to be overridden as a CLI option.

1 Like