How to fix this RCE exploit?

[oubeichen]

I have found this RCE exploit recently. It was originally discovered in 2018. I updated uwsgi to the latest version [2.0.20] but it still exists.

https://github.com/vulhub/vulhub/blob/master/uwsgi/unacc/README.md

https://github.com/wofeiwo/webcgi-exploits/blob/master/python/uwsgi_exp.py

I heard that version 3.0 fixed this vulnerability, but it seems that it is no longer maintained.

I needed to expose the port to the company intranet, but security ordered me to fix the vulnerability.

In other words, how to block the UWSGI_FILE parameter without recompiling uwsgi.

Any suggestions? @unbit

[rdeioris]

Hi, this works only over the uwsgi protocol (and it still works on 2.1/3, it is only that on those versions dynamic apps are no more the default). That protocol is expected to receive sanitized input and in fact you can accomplish the same result even with other variables (you can specify python modules, perl files, shell script and so on).
If you need to expose uWSGI on a public network just do not use the uwsgi protocol as it is meant to be run locally or on a protected environment. You can eventually use the routing system to remove variables, but notice that you are basically fixing nothing, giving that any kind of WSGI/PSGI variable can be changed in this way (included cookies). TL/DR: the uwsgi protocol is meant to be private or protected by a proxy :)

[oubeichen]

Hi, this works only over the uwsgi protocol (and it still works on 2.1/3, it is only that on those versions dynamic apps are no more the default). That protocol is expected to receive sanitized input and in fact you can accomplish the same result even with other variables (you can specify python modules, perl files, shell script and so on). If you need to expose uWSGI on a public network just do not use the uwsgi protocol as it is meant to be run locally or on a protected environment. You can eventually use the routing system to remove variables, but notice that you are basically fixing nothing, giving that any kind of WSGI/PSGI variable can be changed in this way (included cookies). TL/DR: the uwsgi protocol is meant to be private or protected by a proxy :)

Sorry for my English, I hope you can understand my situation. My nginx and uwsgi are deployed on different servers. Both are in the private network. But there are many people in my company, deploying different web services on the inner network servers, thus the security department ordered me to fix the vulnerability.

[rdeioris]

then just use the http protocol (--http-socket instead of --socket)

[oubeichen]

Why not provide a parameter to turn off this behavior?