I ran into an issue recently with an application that I support at work where the vendor does not take security very seriously. I’d prefer not to share the name of the application or the vendor.
This specific application is like a lot of others in the fact that it requires root to be installed. The application also requires root to run. This is not uncommon, as many companies do not invest the time and resources to identify the sudo privileges needed in such cases. Athough, I have am seeing more and more companies address this security hole by allowing their applications to be run as a non-root user.
The issue I ran into was not some security vulnerability where a threat actor could exploit an issue to gain root access. No, this application gives root access away directly. What I am about to reveal shows how some companies can be very short-sighted. This specific application has an API and, among other things, allows scripts to leverage the API for automation purposes (this is an automation related application). So, what could go wrong with an automation application that runs as root?
Let’s take the use-case of creating a Python script to customize the automation. One might want to add logging to their script for debugging purposes and that is where the security gap becomes known. This specific application runs everything it receives through the API as root. This is a very poor design. With the use of various modules, a keen Python developer realizes that he has root access to the host OS (at the risk of giving more details away, this is not a Linux automation application.) and can do things he/she is normally not allowed to do.
This is one of the many risks of running an application as root. If you have to run an application as root I would suggest looking into running the application in a chroot jail or, if possible, run the application in a container, where privileges can be limited so that they do not effect other containers, or the host OS.