Clarification on what is considered a "security issue"

[zacknewman]

Is circumventing configuration settings a "security issue" under whatever threat model is explicitly or implicitly defined? SECURITY.md talks a little about what is and is not appropriate, but I am unsure about this. To me circumventing things like organization policies or attachment limits is a security issue, but I would like to know if such things are classified as such by the Vaultwarden team. Does the Vaultwarden team assume only "official" Bitwarden clients as clients (i.e., a custom client that can cause an exploit or policy circumvention is not in scope and thus not a "security issue" much to my chagrin)?

[tessus]

If it's a client issue, there's nothing the vw team can do, because the clients are maintained by the bitwarden devs.
If it is a server issue specific to vw (happens in vw but not in bw), it is most likely considered a security issue. But I am just a user, thus one of the vw devs would have to answer your question.

[zacknewman]

Perhaps this is pedantic, but clients are not necessarily "maintained by the bitwarden devs" at least from the perspective of the server. While it's likely the case that almost all clients are the "official" clients maintained by Bitwarden, one can certainly write their own client; however your general point still stands: the Vaultwarden team does not maintain any clients (Bitwarden-maintained ones or otherwise).

That may be pedantic or subtle, but it's important when hardening a server and performing pentesting as a server should not assume data it receives is perfect and free from exploitation. I am inclined to believe that any testing that is done is done using the "official" and unaltered Bitwarden clients, but this makes it easier for exploits to trickle into the server since well-crafted or malicious inputs may not be tested on the server since such data is (hopefully) never sent/detected by the clients.

As an extreme example, if Vaultwarden accepted any string sent as a query from a client and executed it on the database, that would obviously be a security issue in Vaultwarden since SQL injection would be trivial—even if that required an unofficial client to send a malicious query. A less obvious example is what I stated in the original question: circumventing configuration settings that are (supposed to be) enforced by Vaultwarden even if such circumvention requires an unofficial client. What is considered a "security issue" by one may not be another especially in the absence of an in-depth threat model, and I am asking this question since I tend to more aggressively classify bugs/issues as "security issues".

For my specific use case, the only users are my wife and I; and we are within the "web of trust"; so such potential "exploits" are not exploits but only because my threat model is defined that way. Vaultwarden is used by other people and organizations whose threat model likely does not include all registered users within the web of trust and thus such "exploits" may very well be a "security issue".

After removing tens of thousands of lines of code and some minor refactoring of my personal fork, there is not much more low-hanging fruit; and I am at the point where further hardening requires an understanding of exploiting assumptions and control flows. I finally have sufficient understanding of the API that my intuition is starting to take over, and my "spidey-sense" is starting to tingle vis-à-vis exploits (at least by my definition when applied to a general admin). If/when I do find such a thing, it would be nice to know if it qualifies as a "security issue" and thus should be privately sent via e-mail per SECURITY.md or if I should simply make a public bug report.

[tessus]

I would suspect, as vaultwarden is described as Alternative implementation of the Bitwarden server API, any security issue you find when sending garbage to the server will be considered a security issue, because the server failed to sanitize the input properly.

Once again, I am not part of the dev team, so I guess we'll have to wait for an official answer.

[BlackDex]

Quick reply from me.
Client checks are nice but should not be the only checks.

All items should be checked server side too.
API calls can be faked or manipulated.

So from my point of view never trust them.

[zacknewman]

OK, I'll just e-mail when I think it's appropriate; and I'll hopefully calibrate my definition of "security issue" as time goes on if/when there are disagreements.