Command injection vulnerabilities
fdcarl opened this issue · comments
There are multiple command injection vulnerabilities in the current version linux-dash.
- The python and node versions of the servers are vulnerable to code injection. For example, with the python server running on my local host, navigating to the URL http://127.0.0.1/server/?module=;ls$IFS-al will output the listing of the current directory.
In the case of the node version, by using a node client commands can be executed directly. For example:
At this point, it is pretty trivial to gain a shell on the server. And since the readme mentions that it may require sudo, there's a good chance that shell will be a root shell.
- In linux_json_api.sh, the final two lines of the script are as follows:
fnCalled="$1"
${fnCalled}
Since all the various versions of the servers (go, node, php, and python) all simply pass an argument to this shell script, some limited command injection is possible. For example, any linux commands that do not need an argument. For example, when running the python version of the server on my localhost the URL http://127.0.0.1/server/?module=whoami will return:
Depending on the permissions of the user running the server, it may be possible to do things like DoS the system by shutting it down.
W00t?! Good find!
The plugin name at the following line
https://github.com/afaqurk/linux-dash/blob/12d38175f00c148a95d390ee33a55b7abf7cc482/app/server/index.js#L35-L36
pluginName needs to be escaped in some way and not piped directly to spawn.
A good solution would be to keep a list of all modules, or load them from the filesystem instead of allowing arbitrary data to be ran.
The following lines are also potentially vulnerable to this attack:
Since module comes directly from GET:
module := r.URL.Query().Get("module")And that because in the bash file there's this:
And of course the PHP file...
Talking about security.. it would be nice to have some sort of login, also, possibly use JWT-Auth.
Thanks.
Actually this needs to be reopened, the patch does not actually totally fix the issue. The function test can be easily bypassed to still get code execution. For example, using the python server on my local machine, http://127.0.0.1/server/modules=$(touch$IFS$9/tmp/testing) will actually execute the touch command and create the file.
@fdcarl Let me evaluate and get back to you. The if statement was supposed to check if the invoked command was a function in that bash script.
So I believe the issue here is now this line: https://github.com/afaqurk/linux-dash/blob/497c573834bfe4ec5070b2d4ec4ee93fd1c7ca07/app/server/linux_json_api.sh#L649
By using the "$(...)", the command is actually being executed here which is before the new type checks.
EDIT: Nevermind, I just realized it was occurring before this line.
@fdcarl that's precise. And the same thing goes for the backquotes (actually didn't test this). Sadly this can't be mitigated in plain bash, so I cooked up escaping in Python, Go and JS.
Python and JS have been tested, but I have not tested Go as I am fuzzy with its regexp library. So, I'll do that tomorrow. I have a branch here and this commit c9d0a31. Some of it may be overkill, so I may trim where necessary.