Keepassxc github1/17/2024 I want to see my statement in context of password managers.Īttack vector: attacker gains access to the unlocked database for a very short period of time and can perform a FULL clear text export. The premise of the CVE comes from a fundamental misunderstanding of KeePassXC's security model. The correct strategy to protect against this is keeping backups of the database. Corrupting the locked KDBX file is enough to achieve this goal. If that were the attacker's goal, they would not need access to the unlocked database. This is different from online web services.Ī password prompt does not even prevent an attacker from locking a user out of their database. There is also no (and cannot be any) "second factor" for "authentication." Again, this is by design of an offline password manager and not a security problem. An attacker can ALWAYS make changes to the database or copy its contents if they get access to it in its unlocked form. Asking the user for their password prior to making any changes to the database settings adds no additional protection against a local attacker. KeePassXC is an offline password manager and hence BY DESIGN, there is no such thing as an "authenticated user". It's probably best for users that want to use the same SSH keys in Linux and Windows to use one of the existing Linux SSH agent replacement solutions.I requested a rejection of the CVE with the following reason: Otherwise the private key can be easily exported by temporarily registering a malicious distro containing only a fake ssh-add executable. Care should be taken to ensure that the WSL distro receiving the unencrypted private key is really one that the user intends to load the private key into. Because KeePassXC is not an SSH agent, it must export the full private key to the real SSH agent that is going to be doing the signing. On my WSL installation I have an SSH agent that I installed and I'm pretty sure I didn't need to disable any preexisting agent to do that. On my Linux system, the SSH agent is a systemd unit, but WSL doesn't normally run systemd. I'm pretty sure WSL doesn't normally run an SSH agent.Windows can stop the distro and unload the SSH agent if it determines that the distro is not being used. I guess KeePassXC would need to somehow monitor WSL distros starting and stopping. KeePassXC should only add keys into distros that are active, not activate inactive distros just to manage transient SSH keys, and distros may become active or inactive at any time after KeePassXC has loaded its keys. Not all WSL distros are active at all times.However, it is possible to write keys over stdio, so KeePassXC could do something like spawn an ssh-add process inside a Linux distribution and pipe the keys into it. I'm pretty sure the \\wsl$\ share doesn't allow socket connections from Windows to Linux because Windows named pipes and Unix sockets are very different. If KeePassXC wanted to additionally load keys into a separate agent running under WSL, it's possible but not as simple as just loading it into WSL. If that agent happens to be the one used for Linux it should just work. It has code that can manage keys inside another agent. According to the documentation (my SSH key is in hardware so I don't use this feature), KeePassXC does not contain an SSH Agent.
0 Comments
Leave a Reply.AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |