• If you are still using CentOS 7.9, it's time to convert to Alma 8 with the free centos2alma tool by Plesk or Plesk Migrator. Please let us know your experiences or concerns in this thread:
    CentOS2Alma discussion

suexec = serious security concerns

R

RayMorris

Guest
I was asked by a senior member of this forum to post about suexec. I am a state licensed security professional doing Linux and Apache security full time for the last fifteen years.

Suexec isn't as well understood as it might be. It has it's use, in a very specific situation, but also has MAJOR security implications, so one should think well before using it. Yet, it's used by default in Plesk.

This is not merely my personal opinion. The suexec documentation starts off by saying:

suexec Apache docs said:
it can cause any number of problems and possibly create new holes in your computer's security. If you aren't familiar with managing setuid root programs and the security issues they present, we highly recommend that you not consider using suEXEC.

That sentence was written by the suexec AUTHORS, not a suexec critic. They go on to say:


suexec Apache docs said:
it has been the decision of the Apache Group to NOT make suEXEC part of the default installation of Apache. To this end, suEXEC configuration requires of the administrator careful attention to details.
...
The values for these settings need to be carefully determined and specified by the administrator to properly maintain system security during the use of suEXEC functionality. It is through this detailed process that the Apache Group hopes to limit suEXEC installation only to those who are careful and determined enough to use it.

"the Apache Group hopes to limit suEXEC installation only to those who are careful and determined enough to use it." Is that you? Your users? Are they careful enough to understand the greatly increased risk from suEXEC and code their scripts properly to mitigate that risk?

The author of the closely related suPHP says:
a security bug in suPHP probably will allow attackers to run commands with root privileges

Clearly they are trying to warn us of a serious risk. "If you aren't familiar with managing setuid root programs and the security issues they present, we highly recommend that you not consider using suEXEC", they say. Does "aren't familiar with managing setuid root programs and the security issues they present" apply to you or your customers? If so, the authors of suexec say you shouldn't even consider using it. (Therefore it is a mistake for Plesk to turn it on behind your back, without you even knowing what it is.)


What exactly is this significant danger, and what is suEXEC useful for? To put it in the simple terms, it's dangerous because it gives all visitors to your site permission to edit the site and to upload their own scripts, then to run those scripts with the full rights and privileges of the site owner. That is opposed to the normal situation where visitors do NOT have permission to change files and scripts run as an unprivileged user.

With suexec, a visitor to the web page has the same PERMISSIONS to change files as if he was given your FTP, telnet, or SSH password. The bad guy is merely missing a MECHANISM to do those things, but that mechanism is provided by any popular PHP script you might install that has a security hole, and many, if not most, scripts have a sufficient hole.

So why in the world would anyone use suEXEC? What is it useful for? suEXEC is useful when (and only when) you have thousands of clients on a shared server. What suEXEC does that's good in that situation is that it prevents scripts uploaded by webmaster A from messing with the data from scripts owned by webmaster B. Webmaster A's scripts can update their data, but webmaster B's scripts can't update the data from A's scripts. That's useful if you're selling $5 hosting accounts and have thousands of webmasters with accounts on the server, because you don't want to have to trust all of those other webmasters.

The problem is, webmaster A's scripts can update not only their own data, but ALL files and folders in A's account. Without suEXEC, you'd chmod a data file 666 so that the script can update THAT file. With suEXEC, permissions (chmod) basically no longer count. Instead of the script being able to update only it's own data, all scripts are now allowed to do anything - to download a root kit and hide it anywhere within that account. This is of course extremely dangerous and we stay pretty busy doing remediation on servers so affected.

Once again, see the top of the suEXEC documentation. It's not just MY opinion that suEXEC is very dangerous, but the very people who created suEXEC take pains to repeatedly warn us of the dangers.

When is it appropriate to use suEXEC and when is it not? Because suEXEC provides some protection against other webmasters with accounts on the same server, at the cost of giving visitors permission to change your site, a somewhat memorable, tongue in cheek but accurate way of saying it is this:

Use suEXEC when you trust people visiting your site more than you trust webmasters hosted on your server.

That implies that there are other webmasters on the server you're concerned about. If it's a dedicated server, suEXEC provides protection from nobody, while making you vulnerable to anyone who visits the site. Is it necessary to list adjectives describing that decision?

Conversely, when should you NOT use suEXEC? It would be silly, to say the least, to run suEXEC if there aren't other accounts on the server. In that case, suEXEC ONLY creates serous security issues with absolutely no benefit whatsoever. Also, the documentation tells us when to not even consider using suEXEC - " If you aren't familiar with managing setuid root programs and the security issues they present, we highly recommend that you not consider using suEXEC." In other words, if anything in this post surprised you, you probably have at least 10-12 hours of studying to do before you should begin to make that decision.


From my fifteen years of experience dealing with compromised servers, I can confirm that the suEXEC authors are not wrong. It is quite frequently that we spend many hours cleaning up a mess that could have been prevented by simply not mindlessly enabling suEXEC without understanding it, or often without even knowing Plesk was doing that at all. Often, the hack code run from suEXEC chains a root kit and that does real damage, requiring the server be wiped and re-installed from scratch, sometimes losing many, many hours of work.
 
It might be interesting to note that it used to be possible to use suEXEC in a way that INCREASED security, but very few people did that and it's no longer practical with the current code.

At one time, you could have webmaster A and webmaster B, each with their own accounts. Instead of running scripts from both of them as the unprivileged user "apache", you could create two NEW users, A_scripts and B_scripts. Scripts from webmaster A would run as user "A_Scripts" and have access only to files writeable by "A_Scripts", not all files owned by A. The wisest admins created A_scripts and saw that it was good, but then new directory ownership and permissions checks in the wrapper made that no longer work.
 
Back
Top