Are Bitwarden aware of, and doing anything to address, the High vulnerabilities that Google have discovered in Bitwarden?
Unsandboxed Password Manager · Advisory · google/security-research · GitHub
Popular password managers auto-filled credentials on untrusted websites | The Daily Swig
Is there a date when this issue will be fixed.
Thank you
Hi, maybe I’m missing something, but I did a test of what was reported in the first link: bitwarden did not autofill either the 4th or the 5th link, even with autofill enabled on page loading
The article from The Daily Swig says:
Both Dashlane and Bitwarden have updated their software…
So I assume it is fixed.
In the linked Google security research, they notate Bitwarden has a fix bitwarden/clients#3860 which has already been merged.
Direct from the article
Both Dashlane and Bitwarden have updated their software although Dashlane, at least, remains unconvinced that the bug represents any kind of security threat.
Hence why in testing this is no longer an issue, thanks for bringing this up though 
Readers of this thread may be interested in my PSA about theft of credentials by auto-fill, including the references linked therein (and especially the linked vulnerability demo).
Spoiler Alert: As demonstrated by the ability of Steve Englehardt’s demo site to “sniff” your login credentials, cross-site scripting can still be used to steal credentials that are auto-filled into invisible forms. The patched security vulnerability only prevents auto-filling from occurring when forms are located on pages that have a CSP sandbox response header or that are located inside sandboxed iframes.
If anybody with the requisite technical expertise (e.g., @mgibson) would be willing to provide a technical explanation of what difference this recent patch makes in the context of the more general XSS vulnerability (which apparently still exists), I would be much obliged.
Hello, folks.
I’m a newbie here, just wanted to clarify one thing about the security fix that was implemented for subj.
https://github.com/google/security-research/security/advisories/GHSA-mhhf-w9xw-pp9x
Frankly, not sure, that I understand why this case poses a security risk for the password manager’s browser extension. Web pages with CSP sandbox property have got even stronger protection against scam activity and what are connections between this CSP directive and security restrictions that are imposed on in-browser password managers. The research also mentions that such web pages are always classified as untrusted, it’s also unclear… Thank you in advance.
Some additional explanation from Bitwarden engineers would certainly be welcome. I also had an unresolved question at the end of my post above.
Thanks for your help! Would be really interesting to hear the opinion of someone from the team.
Btw, from what I can see, the test resource that is used to reproduce this issue, returns in https header the following parameters of CSP sandbox directive.
sandbox allow-downloads
allow-forms
allow-modals
allow-orientation-lock
allow-pointer-lock
allow-popups
allow-popups-to-escape-sandbox
allow-presentation
allow-scripts
allow-top-navigation
allow-top-navigation-by-user-activation
allow-top-navigation-to-custom-protocols
Maybe this is the key point and the sandbox directive is just abused to allow potentially dangerous activities that can be used to perform XSS?
Happy to expand a bit.
The fixes applied to our js-based autofill scripts are to better handle appropriately isolated contexts. This means that the developer of the web page has specifically taken steps to inform us that they don’t trust this content and don’t consider it part of their application, so we shouldn’t either.
The attack being described by Englehardt is one in which the hidden form lives outside of these sandboxed environments without any kind of indication that they are not owned by the top domain.
@mgibson Thanks for the clarification. Is there any technical reason why the auto-fill code cannot detect form fields that are not visible, and refuse to fill those? That would take care of the type of XSS attack described by Englehardt (among others).
@mgibson Thank you for the explanation! Have a good day.
@Dan_B1
I think it’s different things, Sandboxie is designed to isolate app’s process by restricting its privileges and rights (iirc), whilst CSP Sandbox directive instructs browser to strictly process web content on the page. The fix in the password manager just disables auto-fill for this kind of web pages with CSP Sandbox header response.
Couldn’t post a new response, because the forum doesn’t allow me to post more than three posts in one thread…
Would this have any issues if using “Sandboxie” sandbox on mozilla?
Not Mozilla’s sandbox.
dan
There is no technical reason, but there are usability reasons.
You may have realized a trend to transition log in pages to multi-step processes – Bitwarden itself has moved to it recently. This is to facilitate advanced login mechanics like SSO, login with device, linked application unlocking, etc. The best practice for these multi-step pages is to present the username first, and have a hidden field for the password, that will be passed along to the password step, should it occur.
Before anyone points it out, we’re aware the web vault doesn’t work this way, it was a miss in the original feature and we just haven’t gotten the time to get back to it 
If this is the only reason, then it seems that the main drawback of preventing Bitwarden from auto-filling invisible fields would be that the user has to auto-fill twice (once on the username field, and again on the password field), and that it is possible the “autofill on page load” may not work for the password field, requiring a manual auto-fill (Ctrl+Shift+L, etc.) there.
Personally, I always use Ctrl+Shift+L for security reasons, and having to hit this keyboard shortcut twice would be a negligible price to pay for the peace of mind of knowing that only the visible fields are being auto-filled. In fact, I find it a bit unnerving when I auto-fill my username, and then see that the password is already filled when I get to the password screen (which I have discussed in detail in my analysis on Preventing Amazon from “stealing” password).
Thus, if this usability issue is the only thing standing in the way of a more secure auto-fill, then I think that users should be given the option of disabling auto-fill of hidden fields. I am encouraged to learn from your response that there are no technical hurdles standing in the way of such a feature.
Yeah I tend to agree with you. However, I didn’t mean to suggest it was easy, just that it’s in principle possible.
I don’t personally know of a simple way of determining if something is hidden. Since visibility flags are set on the item-level, but are inherited from parents, you have to walk the DOM to determine if something is displayed. Then there are weird ways of making things hidden like positioning it way outside of the view or maybe some other ways I can’t conceive of.
Like everything related to stopping bad actors, I’m sure it’ll be an arms race. I’ll raise your support of that feature. I’m hopeful to be able to get some meaningful autofill improvements in the near future.
Is this about the same issue as the one described in https://flashpoint.io/blog/bitwarden-password-pilfering/ ?
I am also in favour of giving the users an option to disable auto-fill for hidden items AND for items in an iframe.
Regards
M
I really wish people would refrain from posting clickbait sensationalistic blog articles full of misinformation (yes, I’m referring here to the “bleeping” FUD that you linked). I guess this is a sport now that Lastpass got in trouble — trying to take down the “next” password manager product.
The only valuable piece of information in that blog is the link to the Flashpoint report that the blog author is plagiarizing paraphrasing (and poorly at that). And the link to that source was already posted by @mookbav in the comment just above yours.
With regards to the original report by Flashpoint, they describe a well-known, but tricky issue related to balancing legitimate use of iframes by some websites (e.g., iCloud.com) vs. the rare possibility that an advertiser can abuse this function. As noted earlier in this thread, Bitwarden recently released a patch that prevents auto-filling in iframes that have been sandboxed. Flashpoint has not provided any working proof-of-concept demo that can be tested without paying them (!), so it is possible that this latest patch fixes whatever they claim they found. Furthermore, they admit that the only “vulnerability” they found can be readily mitigated simply by changing the URI Match Detection option from Base domain to Host.
All of this just smells like an attempt by Bleepingcomputer and Flahspoint to profit from spreading FUD.