An example of risk when running an application as root

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.


Mini rant…

The rougher part being they probably gain more market advantage in the short run by giving root out like candy because it won’t break anyone’s script for lack of privileges.

It makes techs that know less or don’t care more eager to deploy it… it’s also cheaper to create because the complication of the code base is reduced which also makes it more stable.

When the security hole finally gets out *ahem* when the security hole finally has enough bad publicity, they can go on parade about how they’ve carefully patched it, have restructured their priorities and are now doing 3rd-party security audits (unlike their competition) so they can ride the wave of publicity and turn their ambivalence to security into profit.

1 Like

Maybe they’ve heard of the term DevOps, but clearly, they have no knowledge of DevSecOps, lol.

I’m pushing them pretty hard to close several security holes I’ve found in their application. So far, they been responsive and have provided one-off hotfixes for me or public patches that address most, but not all of the issues.