Closed sneak closed 4 years ago
This is a huge vulnerability I'm surprised exists in the first place. A current work-around is to use the browser extension/Android app and disable the automatic updates for that.
The issue tracking the RCE for vault
(hosted at vault.bitwarden.com
), the web app version, granted to Stripe, Briantree, and PayPal, is over at
All apps with update infrastructure grant "RCE" to their developers. That's the entire point. In fact, it's ironic you are using macOS Catalina, because:
https://www.macrumors.com/2020/05/28/macos-ignore-software-updates/
After updating to macOS 10.15.5 or Security Update 2020-003, this command no longer works, with Terminal displaying the following message: Ignoring software updates is deprecated. The ability to ignore individual updates will be removed in a future release of macOS.
And even if you used Windows, Windows Update does the same thing....why do you trust the thousands of Microsoft developers and not the Bitwarden developers?
Maybe allowing users to permanently reject updates would be valued, but we already tried this in the early 2000s. People would turn off auto-updates and seal the fate of their machines, destined to become a slave to one of the thousands of botnets harassing the Net today. This wasn't a 1-in-a-100 chance; millions of users did this. It's not sound security policy. It doesn't work.
If you really want you can compile Bitwarden from source and remove the auto-update code. But why would you, when it's clearly there for a reason: immediate OTA security patches, in case a severe vulnerability is found. Why would you want to be stuck running a lower, vulnerable version when you could update to the safer one as soon as it is possible?
And if you are worried about the developers getting kidnapped or somehow coerced, why are you using third party software at all? Who's to say that this scenario hasn't already happened with the developers of your browser, operating system, router, mobile phone, cell tower, alarm system....why are you using the Internet at all?
Who's to say that this scenario hasn't already happened with the developers of your browser, operating system, router, mobile phone
The code. It would be nice to also allow users to verify that of Bitwarden before running it, otherwise the point of its source code being public is kind of moot, don't you think?
Minimizing attack surface is nice.
If you really want you can compile Bitwarden from source and remove the auto-update code.
Maintaining a patched fork would be a somewhat painful option for adding a simple switch. I'd just stick with the work-around and be disappointed.
All apps with update infrastructure grant "RCE" to their developers.
And even if you used Windows, Windows Update does the same thing....why do you trust the thousands of Microsoft developers and not the Bitwarden developers?
These statements are not accurate. There are multiple confirmation steps involved, for example, when it comes to updating my OS, whether it be macOS, Linux, or Windows. The vendors are not able to unilaterally alter my OS without my explicit approval.
Furthermore, even if it were true (again, it's not, Windows would be entirely unsalable to e.g. militaries if its autoupdate could not be disabled or mediated/gated by an administrator pending security review), there are many reasons one might decide to trust a world class, nation-state-level security team (the Windows Security Team inside of Microsoft, aided by multiple nation-state-level data security organizations and militaries that use their software internally) that protects software used by a billion+ users, over a half-dozen people who make a $40 app used by a number of people measuring in the low thousands. Not all security teams are created equal.
Do you really believe that aircraft carriers running Windows can't disable or prevent arbitrary OS updates from Redmond? That's not how this works.
In fact, it's ironic you are using macOS Catalina, because:
The ability to ignore individual updates will be removed in a future release of macOS.
This is conflating the issue. I can, and indeed occasionally do, run a version of macOS one or two steps behind the current released version in some instances. The updates are not applied automatically.
If you really want you can compile Bitwarden from source and remove the auto-update code. But why would you, when it's clearly there for a reason: immediate OTA security patches, in case a severe vulnerability is found.
It also provides immediate OTA backdoor patches, in case a severe vulnerability is found in the machines or processes used by Bitwarden to publish releases.
You can't have one without the other.
If you're this worried about auto-updates, shouldn't you avoid cloud-based managers altogether and use something like Keepass?
If Bitwarden or a bad actor tries to replace code anywhere, it would likely be in the web vault and I doubt you inspect xhr each time before signing in.
It's worth mentioning that at that point, if you're trusting the server 100%, encrypting passwords is unnecessary.
This makes zero sense.
:roll_eyes:
How difficult would it be to simply say the version of bitwarden is out of date, click here to upgrade or click here to close the app.
It's important to keep everyone safe but also important to allow untrusting people to have a chance to see what is happening before it happens.
Maybe bitwarden should sign their updates with multiple private keys so that one rogue developer can't push an update? And the auto-updater verifies them. I'm not qualified to participate in this discussion but it could be an idea.
A simple solution, if necessary, would be an Allow automatic updates toggle, potentially with a warning regarding the risks and vulnerabilities of not having an updated application.
A simple solution, if necessary, would be an Allow automatic updates toggle, potentially with a warning regarding the risks and vulnerabilities of not having an updated application.
Perhaps.
But as a user, what kind of information would you look for to determine whether it is safe to upgrade or not?
What do you look for today before you approve an upgrade of each sensitive application and package you use?
Perhaps.
But as a user, what kind of information would you look for to determine whether it is safe to upgrade or not?
What do you look for today before you approve an upgrade of each sensitive application and package you use?
Depends on the type of user you are. If you're a security professional, you know what to look for. If you're just a paranoid user, you'd wait and see from the community (and the experts) how the new release is.
For me personally, it doesn't really matter and I'd probably have auto updates on. I was only suggesting to make a toggle (only if it is necessary) for those who'd like it.
We use GitHub issues as a place to track bugs and other development related issues. The Bitwarden Community Forums has a section for submitting, voting for, and discussing product feature requests like this one.
Please sign up on our forums and search to see if this request already exists. If so, you can vote for it and contribute to any discussions about it. If not, you can re-create the request there so that it can be properly tracked.
This issue will now be closed. Thanks!
I often wait to update almost any piece of software (unless it's a correction of a security bug). Because, in other cases, that update could bring new bugs, so waiting for community feedback from first line, more adventurous users, and also from security experts, makes sense to me and many others.
I like that software is updated. But I like to be in control. Think of Windows 10 and its crappy (to say the least) update management, for instance: I am really, really happy still using Windows 8.1.
This isn’t a feature request, @cscharf. This is a report of a high severity security vulnerability.
I reported this issue on their “community forum” (my thread was locked by Bitwarden staff, which makes it feel more like a “bitwarden corporate forum”), and they said it’s a WONTFIX.
I guess they assume Bitwarden users are fine with Bitwarden having full remote access to all Bitwarden customer machines.
https://community.bitwarden.com/t/three-major-bitwarden-security-issues/14528
Bitwarden have responded to TechRadar regarding this:
TechRadar Pro reached out Bitwarden regarding Jeffrey Paul's post on GitHub and a company spokesperson explained that it does not view the way its software handles updates as a vulnerability but rather as the way in which modern applications keep their large user bases up to date with the latest and most secure software in the simplest and fastest way.
Bitwarden sees auto-updating of its applications as a critical security component for the 99.9 percent of its user base that appreciates them. There has also never been a case where its auto-updates have been compromised in any way.
Additionally, Bitwarden plans to add an auto-update option where users can toggle automatic updates on or off depending on their own preferences. At the same time, the company has committed to rigorous third party auditing to ensure the security of its software and services.
I know I already contributed but I also wanted to link the most applicable xkcd (#538) for this:
If someone wants to know your password they will find it in ways that do not require kidnapping multiple people and coercing them to release a bad software update. If someone wants to pwn every bitwarden user they'll have a hell of a time kidnapping multiple people, building the server infrastructure to command & control thousands of PCs, and centralizing & analyzing all the data they want to collect, all without leaving a footprint that would enable the authorities to catch them.
Think about it: if you had the money to do all that, wouldn't you go after juicier targets rather than a random password manager?
I agree that it is somewhat being blown out of proportion, even though the idea behind it might be worth looking at, like a simple auto-update toggle (not necessarily for this extremely unlikely case but just as a preference feature in general).
It's definitely much easier to go after your target directly than 'take over Bitwarden HQ', unless you're going for a blanket/mass target approach where, well, you're going to end up in jail.
Think about it - the whole world is built on trust and good faith, and it especially applies here when your whole business model relies on it.
How do you order food and eat it without knowing whether the restaurant staff have poisoned your food or have been coerced into doing so? How do you get on a plane or a taxi and know it's not going to be hijacked and crashed? And many more examples. From a philosophical standpoint, the world simply wouldn't be able to run without trust, and you trust people in good faith even when everything is at stake (like your life).
People don't seem to consider this when they're only focused on tech. Of course, you could say that it's a bit different when it comes to software specifically focused on security, but then there's the simple question, how come you trust your anti-virus with full control and administrator privileges over your entire system, especially when it's (for obvious reasons) closed source? They could always push an update that completely compromises your system and information.
I think the tone of this issue is a bit harsh compared to the fact that Bitwarden is open source, so you can most likely compile it for yourself and verify that it doesn't steal your passwords. You could even remove that feature yourself if you want (but as far as I can tell, Bitwarden will add an option to turn automatic updates off). That's the beauty of open source.
Closed source or other cloud based password managers are in a much better position to steal your passwords. While I think it's worth having a conversation (which ultimately seems to be resolved by Bitwarden's response on TechRadar), if you want to go on a crusade (which is what this look like), I can think of much better targets than Bitwarden.
If it downloads and executes code automatically, without user intervention, then I am not in a position to review that code. That’s the whole of the issue.
The current setup grants Bitwarden-the-company full remote access to any machine running the client. It could download and run any software they choose, including without limitation precompiled binaries that are comparatively opaque. It could serve different files to different downloading users.
The issue is not with the way bitwarden-the-software behaves today. The issue is the fact that bitwarden-the-company has total control over my local machine, to download and run any software, open or closed, that they (or anyone who steals their keys) wish.
This is the issue.
Where is the option any on piece of software where I can choose between ethical or unethical patch releases based on the moral character of the developer? That would so make my life safer.
Top notch security analysis on that one.
If it downloads and executes code automatically, without user intervention, then I am not in a position to review that code. That’s the whole of the issue.
If you review the code and compile your own version with auto update removed, you don't have to worry about code being executed automatically do you?
[Everywhere here, by “fork” I mean a change of maintainer, not a source control copy.]
If it downloads and executes code automatically, without user intervention, then I am not in a position to review that code. That’s the whole of the issue.
If you review the code and compile your own version with auto update removed, you don't have to worry about code being executed automatically do you?
Approving preexisting code and maintaining a patch(set) are two materially different things that should not be conflated. Conceptually, a patch(set) is essentially a lightweight fork, and maintaining one, as with any fork, is a statement that you do not feel upstream is not doing a good enough job of maintaining of the code for your purposes. (The purposes can vary—e.g. Debian maintains sprawling patchsets for the sole purposes of compatibility and long-term support.) Therefore telling the people who say Bitwarden is not doing a good enough job with the client code that they can maintain their patches or forks does not constitute a rebuttal of their point (whatever your or my opinion about that point is).
TL;DR: (1) Reviewing updates and systematically patching them are different things, do not substitute the latter for the former; (2) forks mean the original maintainer has failed their users, so their possibility is not an appropriate rebuttal in a discussion with one.
I agree that it is somewhat being blown out of proportion, even though the idea behind it might be worth looking at, like a simple auto-update toggle (not necessarily for this extremely unlikely case but just as a preference feature in general).
My first thought was "yeah, why not just add a toggle button?" (which BitWarden already plans to do sometime).
Then I remember how my current workplace struggles around users not updating their ancient mobile clients (because we don't force or encourage them to) so we have to keep supporting parts of our service which were replaced by better implementations and features.
So a word of suggestion to BitWarden - when you get around to provide this toggle, consider adding an occasional, non-obtrusive, banner on the app reminding users how far behind is their version from the current one (e.g. maybe like Chrome's top-right icon appearing with a different colour to remind users that they better restart it to install a new version).
As for the original complaint - it feels like an attempt to smear BitWarden's reputation to me.
To help clarify further: would using only the FF/Chrome extension, as opposed to the desktop app or the BW vault, mitigate or eliminate the concern which Sneak raised?
So, this whole bug report is based on a "could" and "maybe" ?
Well, America COULD launch a missile attack on Russia, and then we wouldn't need password managers anymore. MAYBE then the world would be a better place.
"Normal users" can not be trusted with the hygiene of their computers. They don't do updates well, and they don't do security well. If, somewhere along the line, it would be discovered that half the Bitwarden users where using an old client with a known vulnerability, then even more people would cry out in anger, wondering why such an important program doesn't have an auto update function. and THAT's a fact, not a maybe.
@sneak your concern is that this software gets downloaded, installed and run without your explicit approval. It sounds like you'd want bitwarden to ask permission (at every step of update process perhaps?) But if that were to be implemented, realistically, how would it address the underlying issue of trust? Would you actually review the newly downloaded package file by file? How would you know that the binary files you downloaded are actually what they claim to be and not something compromised? I'm not asking these questions in patronizing way. I genuinely want to understand how such a situation can be improved. How can we ensure security even in a situation where there's no trust?
And no, run your own fork and compile your own binary is not a solution. If somebody wants to be safe and secure, it's not always viable for them to have coding skills and infrastructure required to run their own fork.
I don’t think that users realize that when they install Bitwarden Desktop, they are giving Bitwarden-the-company full remote access/control of their computer (or at least that user account on the computer) (or anyone who can subvert Bitwarden-the-company).
Fortunately, on macOS, there is per-app directory permission restrictions now (to prevent things like ransomware from being able to read/replace every file under $HOME
, for example). This isn’t the case on the other platforms.
But if that were to be implemented, realistically, how would it address the underlying issue of trust? Would you actually review the newly downloaded package file by file? How would you know that the binary files you downloaded are actually what they claim to be and not something compromised?
In the case of Bitwarden, I’d update manually on a schedule, reviewing the changelog (or source code in the case of major versions). In the event of an issue, I’d be able to determine precisely what code ran and what it did and how to respond, because the code on my local disk would not have been swapped out (and deleted) without my knowledge/authorization.
This protects against a Bitwarden developer compromise, because my local machine would not immediately start running published exploit/backdoor code upon the release of such an “update”. The lag between Bitwarden developer compromise and the code hitting my machine (due to my involvement in the process) would presumably be sufficient for Bitwarden-the-company to detect the issue and resolve it.
Without a user step in between, compromising a Bitwarden release developer is equivalent, practically, to compromising every single user of Bitwarden desktop.
Additionally, what this means is that if a user is granting full remote access to their local computer to Bitwarden-the-organization (which is what unattended automatic updates do), then the encryption in Bitwarden-the-software is irrelevant, as the trust is already placed 100% in the server. There’s no point to encrypting the data if you’re trusting Bitwarden-the-developers to this extent: they already have access to all of the passwords via the remote access to execute arbitrary code on your computer whenever they like, so all of the encryption stuff is just farce at that point.
Really though, the response of “we’re not going to fix it, we designed it that way on purpose” from a developer/maintainer of security software when one reports a major security vulnerability in the design of that software tells you the whole story.
This isn’t the first time this has happened. I reported another security design flaw in Bitwarden almost a year ago (CVE-2019-19766), and they’ve not fixed it and don’t seem to care at all about it.
How is this a Bitwarden issue though and not a software delivery one which a lot use, even security ones? It doesn't matter whether it's security software though because a lot of programs do this and can technically compromise your system and information.
I have Bitdefender as my antivirus which has full control over my system and it automatically updates in the background. Why is this not a concern in that case? I understand your point but this makes it kind of moot as it makes your definition of a "security design flaw" highly subjective.
This is a Bitwarden issue because this is a description of a vulnerability in the Bitwarden software.
The fact that you’ve willingly enabled RCE on your machine for several different publishers is irrelevant; organizations that are serious about the security of their data don’t do that. Software that does that is unsuitable in those environments.
I’ve recently done an organization-wide rollout of Bitwarden in one such organization, which, unless this issue is resolved, will have to be rolled back to protect the integrity of those machines.
I'm with others in that a feature to defer an update indefinitely is the wrong way to go. I think this would open up for various users running very old versions. And this type of update isn't unique to BW, Firefox/Chrome do this, with password managers built in to them. To name a couple.
I just tried deferring the 1.22.1 update with "Later", win10pro asked me for admin rights after restart of BW which would allow me answer no at least once more. Edit: On my mac (catalina) I have to verify twice that I want to run BW after an update.
A middle way would be the ability to defer an update for up to a specific amount of days.
I understand the issue, I really do, but your explanation and arguments make less and less sense.
In the case of Bitwarden, I’d update manually on a schedule, reviewing the changelog (or source code in the case of major versions).
This protects against a Bitwarden developer compromise, because my local machine would not immediately start running published exploit/backdoor code upon the release of such an “update”. The lag between Bitwarden developer compromise and the code hitting my machine (due to my involvement in the process) would presumably be sufficient for Bitwarden-the-company to detect the issue and resolve it.
Are you seriously saying that if you wait enough then Bitwarden will detect if one of its employees was coerced to plant a backdoor in the software (that will likely not be in the changelog for you to notice) and fix it. Just because you have your own schedule for updating?
There’s no point to encrypting the data if you’re trusting Bitwarden-the-developers to this extent: they already have access to all of the passwords via the remote access to execute arbitrary code on your computer whenever they like, so all of the encryption stuff is just farce at that point.
They already can, without an automatic upgrade feature. Because eventually you will install an update manually. And the changelog won't say that "hey, we planted a backdoor so we can steal all your passwords". This is true for all cloud based software (and non-cloud based software for that matter).
Oh wait, Bitwarden is actually open source. So you probably have much more control over what happens on your computer.
Now to the "not everyone is a tech expert argument": chances are that those people won't even disable the automatic updates anyway.
So here is the thing: I think Bitwarden is seriously at fault here, because of their prior communication and failure to react in a positive way. I believe having an option to disable automatic updates would have prevented a lot of damage in public opinion and ultimately would have resulted in a way "cheaper" solution.
But the amount of energy you @sneak invested in bashing Bitwarden and making them look like shit could have been well spent in many other places in my opinion. A few ideas:
Again, I see why Bitwarden's communication led you here, but at the same time: Bitwarden is a decent, modern and open source password manager which isn't common, so I really lack the appreciation from your communication, or at least, you know... not making them look like shit. Even if you have some truth in what you are trying to say.
Anyway, I don't think this conversation is productive in any way. Allowing to opt-out from automatic updates should really not take more than a couple days to implement (and that's an over-estimation). I really hope Bitwarden will react in a positive way, even if they disagree. It just doesn't make sense to fight this wish, to turn off auto updates.
There's definitely nothing wrong in having more options. In my opinion the best way to go about it, if necessary, is an auto update toggle (enabled by default with a warning on disabling) with aggressive update pop-up prompts if turned off and a 'later' button which makes it appear again after a certain duration.
Regarding the 'RCE' argument, however, and whether it's a critical security vulnerability, I'd say that is a subjective issue because you could also argue that forced updates can immediately patch any vulnerabilities and allows for more safety. If it's an objective and blatant security vulnerability, you know the Bitwarden team would patch it immediately.
Back to my Bitdefender example, there is no way for me to turn auto-updates off there too. Makes you wonder why this seems to be a consciously implemented feature in a lot of software. You're probably far more likely to be affected from some vulnerability or exploit that appears in the software at some point, than a developer injecting malicious code or backdoors.
Who do you think the average Joe will blame once their passwords get compromised by a vulnerability that was patched in a new update, himself for not updating or Bitwarden for having the vulnerability in the first place (and probably stop using their products altogether)? I feel like it's going to be the latter. Even so, they're not the type who are going to do research before updating, they will just eventually update to get rid of the prompt.
Anyway, I think the biggest and main issue here is that this was posted as a 'bug' and a 'critical software security vulnerability' rather than a feature suggestion since it's clearly something subjective.
All users should have the latest version of Bitwarden installed on their computers and the current system allows that. Otherwise users would just keep postponing the update.
I would appreciate it if you kept the personal attacks out of this thread @sagikazarmark and kept the discussion on-topic. I’m not bashing anyone, and neither should you.
I'm with others in that a feature to defer an update indefinitely is the wrong way to go.
The owner of the device is the authority on what software is allowed to run on it.
For all the reasons already explained in this thread, we have no plans to remove auto-updating from our desktop application.
If you don't want auto-updates to occur for whatever reason, you can easily disable them by setting the following enviornment variable on your machine:
ELECTRON_NO_UPDATER=1
We don't recommend users do this unless they know exactly what they are doing, which is why it is hidden in an envionrment variable.
Alternatively, you could also use one of the many portable versions of the app that does not support auto-updates.
Describe the Bug
The Bitwarden Desktop app automatically downloads updates and replaces its own code with those updates, without user intervention, which is then executed on the next launch of the app. This constitutes a Remote Code Execution (RCE) vulnerability.
This permits the Bitwarden developer(s), or anyone compromising or coercing the Bitwarden developer(s), to backdoor every single Bitwarden installation in the world and steal all of the passwords stored in every Bitwarden desktop user's database.
Steps To Reproduce
Run Bitwarden Desktop when an update is available.
Expected Result
A prompt to update is given before new code is downloaded.
Actual Result
The new code is automatically downloaded and replaced on disk.
Screenshots or Videos
^ both of those buttons mean "run potentially-backdoor code that I don't want".
Environment
Additional Context
The fact that, of all things, a password manager would grant FULL REMOTE CODE EXECUTION to its developers is insane. The very fact that you would ship a feature like this means you are in no way qualified to hold keys or authentication credentials that allow you to publish a new version that could, at your sole option, backdoor everyone's installations and steal all the passwords of every single user of this software.
Literally the only thing keeping the passwords safe is the good intentions of the Bitwarden team, and the good intentions of anyone who's able to compromise those users/computers.
This isn't about "we'd never do that". If a family member of yours were kidnapped and that were the demand, you'd do that, and I'd cheer you on for doing so, because physical safety is more important than all of the passwords possessed by every user of Bitwarden, which is what would then get compromised in that situation. If your national military kidnapped you and put a gun to your face (or simply threatened you with jail) and made you do it, you'd do it, and again, I'd cheer you on for doing so.
The error is not "Bitwarden's developers aren't secure enough", or "Bitwarden's developers aren't trustworthy enough". The error is that Bitwarden staff are ever in a position to automatically replace the code on every single Bitwarden Desktop user's system and steal all the passwords for everyone ever.
Updates must be manually approved before install, or Bitwarden's clientside encryption of passwords is pointless, because if Bitwarden wants to (or is coerced to), an update can be pushed that steals all of them instantly.
Note Also
This vulnerability exists at
vault.bitwarden.com
and is unpatchable by design, because web applications by default must trust the validity of the application sent by the server (as well as any third parties included via<script>
tags and the CSP, see comment below) at all times.Desktop applications do not, though, and it seems this "100% server trust" model from the web has been ported over to the desktop unnecessarily. (It's worth mentioning that at that point, if you're trusting the server 100%, encrypting passwords is unnecessary.)