I came across a few articles recently released about some security vulnerabilities in Bitwarden and a few other cloud based password managers. I cannot see any advisory notice from Bitwarden themselves.
Hopefully someone from Bitwarden can comment on this and point to a status page or what version contains a fix for these
https://www.infosecurity-magazine.com/news/vulnerabilities-password-managers/
Hi @gooseleggs let me know if you had a chance to read the blog above which links to the full report.
Thanks @debit. I did see it, and now read it. However while it is written as an edge case, the bit I am interested in is an expansion of this paragraph:
“All issues have been addressed by Bitwarden. Seven of which have been resolved or are in active remediation by the Bitwarden team. The remaining three issues have been accepted as intentional design decisions necessary for product functionality.”
How many of the seven are outstanding?
What versions addressed the ones that were remediated (May be multiple versions)?
When will the fixes be released for the remaining?
The blog article is a summary of Bitwarden’s full report on the matter. The “expansion” is the report itself, which is linked at the bottom of the blog article:
@dwbit For Issue 6: Icon URL Item Decryption, the report states that Bitwarden is considering the following mitigation: “Explicit hashes of icon URLs, set by the client, are being considered for development.”
I would like to make the Dev Team aware that there are three open Feature Requests that might provide alternative (or additional) pathways for defending against the type of attack described in Issue 6:
- Custom icons for vault items, folders and collections
- Allow disabling website icons globally
- Sync Bitwarden settings, like "Lock after X minutes" or PIN
All of these would give users the option to avoid troublesome icon fetch messages being generated in the first place.
@grb All of the above linked proposals would fail to remediate the issue without proper care, mainly since the server can downgrade / unapply these protections.
The fix is already deployed, but inactive unless your account either uses per vault item keys or your account is upgraded to V2 encryption [1]. (sdk-internal/crates/bitwarden-core/src/key_management/account_cryptographic_state.rs at 4ffddfe5fb69d3e93d110b4dda9db4ccd017b203 · bitwarden/sdk-internal · GitHub). Neither of these are yet rolled out, but are close to being rolled out.
I’ll respond to each of the links individually, but this depends on the exact assumptions made:
- Custom icons for vault items, folders and collections
- Suppose you implement this by adding a new “vault icon” field that is an encrypted copy of the SVG / PNG / JPEG, then the server could simply omit this, or replay you to an old, saved copy of the vault
- Allow disabling website icons globally
- Does this mean per account? If so, how is this setting stored, is it encrypted (and authenticated)?
- Even if it is a new “settings” property that is encrypted and synced on the account, then this could be downgraded by the server by omitting the field or replaying your account to an old recorded state
- Does this mean per account? If so, how is this setting stored, is it encrypted (and authenticated)?
- Sync Bitwarden settings
- The same applies here, either the synced settings can be omitted entirely, or a replay of an old vault can happen.
One of the biggest challenges is to migrate users with proper protection against downgrades to the old, vulnerable vault format. This comment applies to most of the remediations in response to the ETH report.
I’ll also note that the underlying cause of issue 6 is that integrity is applied at the field level, not the vault item level, and the URI feature is merely one pathway to abuse this. The proper fix here is to extend cryptographic integrity to apply at the vault item level instead of the field level.
[1]: (V2 encryption is the first step necessary in addressing the BW08/BW09, by deploying a completely new protocol for organization membership, that has sender authentication. For this, users first need signature keypairs).
If I may say so – this topic seems closely related to this “in-progress” item of the new roadmap (and it would be interesting to know more about it’s changes, implications and security enhancements – now or later…):
Sure, @dwbit 's post that you link is referring to user account encryption v2, which as mentioned in my former post is fundamental to at least the organization-related remediation work. Account encryption v2 provides users with a cryptographic identity (signature key pair), which is fundamental to key sharing building protocols that have sender authentication.
Further, it has a non-downgradeable “signed security state”, which prevents the downgrading attacks that would appear for most trivial attempts to fix the reported issues.
Anyone concerns about this news on Bitwarden and other 2 popular password managers’ security weakness, e.g. 12 demonstrated attacks on Bitwarden.
Did anyone hear anything from Bitwarden?
@Jetpack0x93 Welcome to the forum!
I moved your post into this corresponding thread. So, don’t miss the posts above.