In the last post , I conducted a “guided tour” on Linux privilege escalation methods. Today I am analyzing the privilege escalation vector through insecure SUID/SGID permissions. Therefore, more console and less words.


What is a SUID?

The change of ownership bit or SUID (Set User ID) is the permission of the Linux file system, which allows you to run the executable file on behalf of its owner. It is needed because many actions in Linux (for example, opening a raw network socket) require superuser privileges. A well-known ping command uses network sockets and therefore must be run as root. How can I allow a regular user to use the ping command? You can issue sudo to the necessary commands. But imagine that on a conditional Linux machine there are 100 users and there are about 20 privileged commands. And how then to manage sudo permissions for all this "wealth"? Not the most elegant solution, is it? On the other hand, the change of ownership bit greatly simplifies the process. The owner change bit will tell the system that all 100 users on the system run the ping command as root.

So, you and I understood what SUID is, but hackers also understand this. In most cases, privilege escalation through an executable with SUID is possible if:

  • executable file allows you to interact with the file system ;
  • the executable one way or another has the ability to exit to the command line .

Example with curl

Let's figure it out in order. Suppose I find that the curl executable is set to the owner change bit, we can understand this by the letter s in the file permissions.

setting SUID for curl
Setting the SUID for curl

The exposed SUID allows you to download the file as root. Since the file is downloaded by root, it is also the owner of the file.

Download a file via curl with SUID

Well, what to do next? I will try to replace some sensitive file:/etc/passwd fits perfectly. First, copy the existing file to the attacker's host.

I am downloading the file with scp

In the resulting file, I’ll change the user and group ID for user bob from 1000 to 0 (which corresponds to root).

Original bob user ID

I’ll download the edited file to the attacked host using the curl command.

Successful privilege escalation

Example with systemctl

I think it became clearer, but let's look at another example: I picked up the password for bob and got access via SSH. I look around and study the environment - in this case, the find command.
find/-user root -perm -u=s -type f 2>/dev/null 

Feel the difference : on the left is linpeas output, on the right, essentially the same output, but the find command was entered manually

I find in the output of the find command the binary/usr/bin/systemctl. Since I have access to systemctl, and even in the context of root (after all, I found this binary by searching for files owned by root and set to suid), I can start a malicious service.Special kung fu is not required here, just create a text file with a description of the service.

Example service description file
[Service] Type=oneshot ExecStart=/bin/sh -c "id >/tmp/output" [Install] 

Demonstration of the service

Nothing prevents me from changing the service, for example, writing a back-connection to it. It remains only to raise the handler (handler) on the attacker's host and restart the service.

Successful privilege escalation. Handler upstairs, service launch downstairs

I gave examples in which the owner change bit is set for the root user, but this vector can also be used to compromise less privileged users of the system. As you can see, the change of ownership bit is a pretty security-sensitive “thing” and it may turn out to be a Linux system hardening bottleneck.

What's next?
The main thing in this vector, as elsewhere in offensive, is to understand how everything works. I recommend repeating a couple of examples in order not only to understand, but also to realize the information received. For practice, you can raise the stand yourself and experiment, or you can combine business with pleasure and search for write up’s hackthebox of outdated machines, where a vector with SUID was used to increase privileges. Resolve them, upgrade your account, talk about it at the interview. Over time, you will understand that write up’s deprive you of the feeling of victory, and when you feel the strength in yourself, you can use the accumulated knowledge.

More specific examples of privilege escalation via SUID can be found here , including the one that we reviewed.

What about the SGID (Set Group ID) ownership change bit?

In general, the essence is the same, but some tricks will be more difficult, for example,/etc/passwd will not be able to be rewritten in this way, since the root group cannot edit the file. Yes, and the service cannot be restarted.

The permissions of the/etc/passwd file do not allow the root group to change

Attempting to restart the service

There is an option with an interactive shell, for example via vim. To do this, use the command:

vim -c ':py import os; os.execl("/bin/sh", "sh", "-pc", "reset; exec sh -p") 

The root group allows you to read the contents of the/root directory, but you cannot even read the contents of the id_rsa file. The SGID ownership group change bit provides incomparably less privilege escalation options.

Directory contents/root


For safe hardening, I recommend that you exclude the presence of the owner/group change bit for the executable files listed. It should be borne in mind that the deletion of the owner/group change bit may be followed by incorrect service behavior and troubleshooting. And you definitely shouldn’t delete the owner change bit for all executable files.


In the article I used examples from the best, in my opinion, collection of gtfobins privilege escalation.

  1. curl
  2. systemctl
  3. vim

If you have an interest in parsing other cases of privilege escalation via SUID/SGID (or not, it doesn’t matter), write in the comments or in PM. In the next post we will discuss how to get a stable shell . Successful hunting !.