is not in the sudoers file. This incident will be reported.
In the *best-case* scenario, you can run any command (even `sudo /bin/bash`) as root (without a password):
Matching Defaults entries:
env_reset, mail_badpass, secure_path=/usr/local/sbin\:/usr/local/bin\:/usr/sbin\:/usr/bin\:/sbin\:/bin
User <username> may run the following commands:
(ALL) NOPASSWD: ALL
Another more common example is that you can only execute a certain program or the `NOPASSWD` tag is not set meaning you do need to enter the *current user's* password:
User may run the following commands:
(ALL : ALL) /usr/bin/find
$ sudo find
Password:
Another common syntax to recognize is *which other user* you execute the command as, as this is not always `root`:
User may run the following commands:
(administrator) /usr/bin/cat
$ sudo -u administrator cat
### `env_keep`
Sometimes the program itself is not exploitable, but there is an `env_keep` option. This option allows you to keep environment variables while executing the program, that normally get cleared.
$ sudo -l
Matching Defaults entries for user on this host:
env_reset, env_keep+=LD_PRELOAD, env_keep+=LD_LIBRARY_PATH
User user may run the following commands on this host:
(root) NOPASSWD: /usr/sbin/apache2
Normally no environment variables are set at all (`env_reset` is doing this). All names added via `env_keep+=` can be set in your shell session, and will be kept when you run `sudo`. \
If it were `!env_reset` instead, all variables would be kept. This is even more exploitable as many ways exist to use environment variables for unintended behavior (see [#environment-variables](https://book.jorianwoltjer.com/linux/command-exploitation#environment-variables "mention")).
## SetUID
Set User ID (SUID) binaries are programs that when executed by anyone, will perform actions with the **permissions of the owner** of the program. All programs are files, and the SUID bit on a program is just a permission like read/write/execute that you might be familiar with. The SUID bit can be seen as an `s` character where there would normally be an `x` for executable permissions:
$ ls -la /usr/bin/sudo
-rwsr-xr-x 2 root root 168136 Jan 5 2016 /usr/bin/sudo
^ ^ ^ ^
SUID SGID user group
When this `s` permission is set by the owner, it means that for anyone executing this program, it will be like the owner of the program ran it. If the file owner is root for example, then you would be executing the program as root. This sounds very dangerous because it is.
{% hint style="info" %}
Note: The Set Group ID (SGID) bit is very similar. When executed by anyone, it just sets the permissions to those of the **group** owner of the file. The second name in the `ls` output is the group, so you can see what permissions you would be getting
{% endhint %}
As a defender, you need to be absolutely sure that the program that is executing cannot do things other users shouldn't be able to do, like reading files, writing files, or executing arbitrary commands. Programs like `sudo` in the example above are secured by asking for a password and checking permissions very carefully. But this is also why a vulnerability in sudo or any other SUID program is a big deal.
To find all files on the system having the SUID or SGID bit set, you can use a `find` command:
```shell
find / -type f -a \( -perm -u+s -o -perm -g+s \) -exec ls -l {} \; 2>/dev/null
```
An important note is that executing these programs **keeps the environment variables** that you set. This opens up a whole load of new inputs the binary does something with. The [#usdld\_preload-and-usdld\_library\_path](https://book.jorianwoltjer.com/linux/command-exploitation#usdld_preload-and-usdld_library_path "mention") variables are *filtered*, but the [#usdpath](https://book.jorianwoltjer.com/linux/command-exploitation#usdpath "mention") variable is *kept*! If developers aren't careful to use absolute paths, this resolution can be overwritten by an attacker.
{% hint style="warning" %}
**Note**: *Shell scripts do not use the SUID bit*, these only matter on ELF executables. This was a decision made because SUID binaries should be as secure as possible ([more info](https://unix.stackexchange.com/a/2910))
{% endhint %}