Responsible Vulnerability Disclosure Policy

[koromodako]

Hi,

First of all, thank you for this great project 👍

I'd like to report some security issues. I'm looking for a responsible vulnerability disclosure policy that I should follow to report these vulnerabilities in a responsible way.

Thank you

[koromodako]

Looks like someone already reported a vulnerable dependency in #174, let me know if reporting is supposed to be done in public issues on this Github repository.

[thiagoralves]

Sure, you can disclose it here as an issue

[koromodako]

Here is a list of some issues and possible mitigation that could reduce associated risks.

Regarding webserver app, I noticed that:

• user password is stored as plain text in openplc.db (CWE-256) => the app could store bcrypt or argon2 hash instead

• default openplc password is hardcoded (CWE-1393) => the installer could generate and print a unique password at runtime

• the app binds a hardcoded unrestricted IP address (CWE-1327) => the app could make this parameter customizable and default to 127.0.0.1 instead

• the app allows code injection in two Hardware options (psm_linux and psm_win) (CWE-94) => the app could allow the administrator of the server to disable these options to prevent server takeover

• the app allows to change the hostname of the server => the app could allow the administrator of the server to disable this option to

[thiagoralves]

Thank you for the report. Just a few comments:

1. This has been reported already in multiple other places and even CVEs. It is being addressed in the dev-python3 branch of the new runtime at github.com/autonomy-logic/OpenPLC_Runtime. Also, there are plans to add https support which will also protect against getting the hash over the wire.
2. Noted
3. Noted
4. Given that OpenPLC is a Programmable Logic Controller, there must be ways for the user to inject his/her code, otherwise it wouldn’t be “programmable”. This is totally expected and is not a vulnerability, as the feature is behind authentication (you must be logged to be able to configure and enable PSM). So far there hasn’t been any reports of known ways to inject code unauthenticated
5. Same as 4

[koromodako]

Thank you for this answer.

I'd like to elaborate a bit more on points 4. and 5.

Lets say that we have student training on a OpenPLC powered lab, how can we restrict access to the underlying layer (I mean the OS layer of the server running OpenPLC) ?

On a real PLC one can upload a program but should not be able to run code in OS, say VxWorks for instance (except in the presence of vulnerabilities).

There is a difference between being able to change the program running on an OpenPLC server and being able to tell this same server to shutdown adding a short piece of code in PSM based on some os.system call.

Maybe OpenPLC could setup a minimal Role-Based Access Control feature to prevent specific users from using features allowing to take over the underlying operating system. What I mean is that there is a difference between a server administrator and an OpenPLC user.

[thiagoralves]

You don't have to write code on PSM to make OS system calls. You can write that straight in the PLC program itself by declaring C under pragmas. Many other vendors (with a more open mindset) like PCWorkx, TwinCAT and even CODESYS allow that type of thing as well, where users can declare C code or make syscalls. If the user is restricted even to upload a new PLC program because of that, then the PLC is useless. This is not about security or vulnerability. This is about openness, and that's the concept behind OpenPLC, to be open, without restrictions. Obviously that comes with a risk if one does not know what he/she is doing. With great powers comes great responsibility. In case of students, just place the OpenPLC Runtime inside a VM. Then you get the isolation you need.