OctoPrint's security policy clearly states that "Attacks that require the user to expose their OctoPrint instance on the public internet or another hostile network" do not qualify as vulnerability. It warns you if you do this anyway, you have to explicitly accept quite a few dialogues, from when you access from a non-local IP to the wizard, where you explicitly state that you understood that exposing an OctoPrint instance is a very bad idea.

Also, with your arguments I could right now report quite a lot of "vulnerabilities" to any OS. "Your Linux installation is just one bad line of iptables config away from accepting every connection." ssh, which is a far bigger security concern, has a lot less warnings not to expose it.

All in all I do not think OctoPrint needs to get bloated, just to prevent every specific corner case of stupid users ignoring all warning that are there.

I disagree with your Linux argument and with your bloated argument.

"Your Linux installation is just one bad line of iptables config away from accepting every connection".

You're mentioning an entirely different risk. I could mention 100 more but that's irrelevant to this one. Besides most 'ssh' devices are not physical devices that have the ability to as I mentioned 'physically reach 250C+ temperatures, potentially unattended for prolonged periods of times'. And without being noticed if the firmware upgrade is indeed malicious and doesn't report real numbers. Also, keep in mind that firmware is on a lower level than OctoPrint. OctoPrint reads and listend to what firmware reports, if the firmware is malicious we're in for a whole different game. Hence, the utter importance of protecting firmware. This risk described here is very specific to 3d printers, in this case the gatekeeper is OctoPrint.

"not think OctoPrint needs to get bloated".

There is nothing bloated about the abilities to harden your OctoPrint instance. I suggest to always use a secure-by-default method but for backwards compatibility would understand silently introducing this feature without enabling it by default (first). This means nothing gets bloated, and you do give this ability to users who want to further harden their OctoPrint instance.

And yes, it's stated in a policy, but do you think most people in real-life read that, let alone fully understand all implications? It's beside the point too, a policy and user behavior are very different from technical enforceable controls.

Lastly, if security warnings are currently fragmented over multiple places and you experience that as 'bloated'. We could consider adding a 'security tab' somewhere and list all hardening recommendations in one place. That would not be a bad idea either to centralize this information and make it more easily accessibility.

I currently lack the bandwidth for an in-depth response, but just for the record, you already can disable the Plugin Manager (which is itself a plugin) through config.yaml, by adding pluginmanager to plugins._disabled. That way, no more plugin installs will be possible through the UI and/or API as that's completely implemented in the Plugin Manager plugin. Updates are implemented in a different core plugin and thus won't be affected by this. So, hardening your install that way is already possible.

You're mentioning an entirely different risk. I could mention 100 more but that's irrelevant to this one. Besides most 'ssh' devices are not physical devices that have the ability to as I mentioned 'physically reach 250C+ temperatures, potentially unattended for prolonged periods of times'. And without being noticed if the firmware upgrade is indeed malicious and doesn't report real numbers.

No, I still stick to my original argument. Impact on CIA is equivalent, it does not matter if the system has a hotend in it or if the ssh interface allows you to access highly sensitive data about a customer's religion, his passwords or sexual orientation. In all cases it is a breach with high impact. And in both cases I would tell a customer the same thing: only expose it to the internet if you absolutely have to. And if you have to make sure you have working authentication and authorisation mechanisms and make sure users have strong passwords. Why do I tell this? Cause OctoPrint tells you this, at all relevant points.

Also, keep in mind that firmware is on a lower level than OctoPrint. OctoPrint reads and listend to what firmware reports, if the firmware is malicious we're in for a whole different game. Hence, the utter importance of protecting firmware. This risk described here is very specific to 3d printers, in this case the gatekeeper is OctoPrint.

The problem with your argumentation is that you implicitly assume that protection measures are bypassed, basically someone needs to already have got admin access by another vulnerability or the admin must have blindly installed a malicious plugin (or something similar). If we take the CVSS spec as a reference point, you have to consider each step separately. And then you will see that describing/rating your scenario implicitly assumes an already broken authentication, so AV would be Local or even Physical. Even with a high integrity impact this could not become a high score anymore. Basically you assume a whole kill chain including an exploitable authorization bypass or config mistake and use this to give a latter point in the chain a higher exploitation probability. But if an attacker gets to the point you're describing they can do a wide range of things that are equally bad or worse. Bottom line again: the problem is not how OctoPrint handles plugins, but a user who ignored a lot of warnings and decided to act despite of high risks.

And yes, it's stated in a policy, but do you think most people in real-life read that, let alone fully understand all implications? It's beside the point too, a policy and user behavior are very different from technical enforceable controls.

At some point you have to trust in the ability of people setting up an environment. I agree with you to the extent that the defaults should be as safe as possible. But they are in the case of OctoPrint. As foosel wrote, you can even disable plugins. Or you just don't use them. In any case anyone administrating an instance needs to be aware of the implications any plugin brings. After all it's python code and anything could be in there. So either check the code or trust the plugin without a check, which can be a stupid idea with any library, piece of code or binary. All of this is covered by OctoPrint's security policy and even put in idiot-friendly UI warnings, do you really think a switch in a text config file will be used responsibly by users who you consider too negligent to read a security policy? I don't think so.

I do like your persistence. But I also like the assume-breach approach and the defence-in-depth methodology.

Also I didn't formally risk rate this using CVSS and yes, you're right CVSS or similar would result in a lower severity because multiple breaches need to be assumed for this to succeed indeed. However the impact could potentially be extreme (once again: fire).

Boldly stated: there is not need to speak about privacy and sensitive data if the user is no longer alive.

I understand we have a different opinion about this so let's agree to disagree. As a former firefighter and working in cyber security I am strongly opinionated about hardening cyber security of physically high-risk devices such as 3D printers. (Yes, depends on many factors too). This issue is fairly specific and I believe it is a sincere improvement for most users. Even if the default is not secure, it gives the ability to users to further harden their system. I don't see what could possibly be wrong with that.

Boldly stated: there is not need to speak about privacy and sensitive data if the user is no longer alive.

I understand we have a different opinion about this so let's agree to disagree. As a former firefighter and working in cyber security I am strongly opinionated about hardening cyber security of physically high-risk devices such as 3D printers. (Yes, depends on many factors too). This issue is fairly specific and I believe it is a sincere improvement for most users. Even if the default is not secure, it gives the ability to users to further harden their system. I don't see what could possibly be wrong with that.

Rhetorically speaking it is not ok to suggest "let's agree to disagree" and then make another statement. This could be seen as an attempt to make the statement immune to further discussion or criticism. ;) But I agree to disagree about the technical arguments. As someone who also works in infosec (following your assumption that it is applicable to cite one's field of employment in order to strengthen arguments), my opinion is equally strong. Sure, control over a hotend is something sensitive. But industrial systems are far more problematic (think containers full of molten steel) and securing SCADA systems follows exactly the same things I mentioned above: do not expose them, if you do make damn sure it is secure and you know what you're doing. Many of those still run on Win XP cause you can't write off a 45 million investment after a few years, just cause the OS went out of support. And still they can be run safely if you do not expose them to a sensitive network. Why the comparison? Cause it is the same with OctoPrint. Every user needs to create is own threat model, including rating the impact and the potential damage. My 3D printer is on a fireproof surface, has a smart smoke and temperature detector above it and cuts power with a smart plug when it is triggered. So the impact of your scenario in my personal case is zero. Just because other people might be more negligent is not a reason to bloat OctoPrint - users who do not read the small print will likely not think about placing their printer safely. They did their threat model implicitly and accepted anything that might happen.