The following article describes common security issues regarding misconfigured sudoers’ files. The article focuses on a single entry which contains several security issues:
hacker10 ALL= (root) /bin/less /var/log/*
The article is split into the following five chapters:
- PART 1: Command Execution
- PART 2: Insecure Functionality
- PART 3: Permissions
- PART 4: Wildcards
- PART 5: Recapitulation
The last issue with our example “sudo” command is the wildcard (*).
Excerpt from the “sudoers” man page:
Wildcards
sudo allows shell-style wildcards (aka meta or glob characters)
to be used in hostnames, pathnames and command line arguments in
the sudoers file. Wildcard matching is done via the POSIX glob(3)
and fnmatch(3) routines. Note that these are not regular
expressions.
* Matches any set of zero or more characters.
? Matches any single character.
[...] Matches any character in the specified range.
[!...] Matches any character not in the specified range.
\x For any character "x", evaluates to "x". This is used to
escape special characters such as: "*", "?", "[", and "}".
POSIX character classes may also be used if your system's glob(3)
and fnmatch(3) functions support them. However, because the ':'
character has special meaning in sudoers, it must be escaped.
For example:
/bin/ls [[\:alpha\:]]*
Would match any filename beginning with a letter.
Note that a forward slash ('/') will not be matched by wildcards
used in the pathname. When matching the command line arguments,
however, a slash does get matched by wildcards. This is to make
a path like:
/usr/bin/*
match /usr/bin/who but not /usr/bin/X11/xterm.
Exceptions to wildcard rules
The following exceptions apply to the above rules:
"" If the empty string "" is the only command line argument
in the sudoers entry it means that command is not allowed to be
run with any arguments.
As the wildcard in our example is part of the arguments and not the path name, it allows us to break out. One way to do this is shown in the following example:
Another way to break out would be the following command:
When in less it is possible to use the “:n” command to switch to the next file in the file list:
Solution
Wildcards are extremely dangerous. Don’t use them if you are not 100% sure that a malicious user is able to abuse it.
The more secure solution to the issue would be to write a script which does input validation and is the only thing that is allowed to be called using “sudo”.
It is possible to prevent malicious user from doing path traversal by denying such pattern:
hacker10 ALL= (root) NOEXEC: /usr/bin/less /var/log/*, !/usr/bin/less *..*
to prevent path traversal and space separated parameters:
hacker10 ALL= (root) /bin/less /var/log/*
hacker10 ALL= (root) !/bin/less /var/log/*..*
hacker10 ALL= (root) !/bin/less /var/log/* *
instead of last one, you could use also:
hacker10 ALL= (root) !/bin/less /var/log/*[ ]*
or
hacker10 ALL= (root) !/bin/less /var/log/*[[\:blank\:]]*
Hi,
There’s any way to compile a set of SUDO RULES and generate a decision tree?
I’m thinking about a path to test (pre compiling) a SUDO rule be aware of possible issues before send it to a production system.
Let’s say we have two rules:
1) Rule 1: Allow all commands into a group os hosts;
2) Rule 2: Allow a few commands into all hosts;
Then, the user get access to both rules. Is it allowed to do anything on all hosts?
I’m looking for a path to teste such cases before save the rules into LDAP.
This article is six years old, but you realize that your system is compromised by allowing less to run as root, right? You can enter “!sh” to get a root shell in less (also vi and other tools) this way.
Hi Daniel
That’s true, thanks for your input.
Our sudoers article is split into five chapters. This chapter here focuses only on wildcards. The command execution vulnerability you mentioned is described in chapter 1: Dangerous Sudoers Entries – PART 1: Command Execution. An example can be found there.
As you mentioned, there are really a lot of tools that allow the execution of commands. Always read the manpage of every tool you can execute using sudo!
A nice and more exotic one I saw some time ago is tcpdump. You can write the network traffic into a file and specify the max-size of this file. If the max-size is reached, a new file is created and a postrotate-command is executed by tcpdump. This command can be specified using the -z option. So if you can run tcpdump using sudo, you can exploit that.
Example exploit:
Have fun :),
Emanuel
I apologize for not reading the series; a search dropped me into this article. Please feel free to delete my ignorance. :)
If you give an entire script sudo, isn’t there a danger the script would be rewritten and then execute any and all commands elevated via sudo?
True. Same accounts for binaries that help to spawn shells when running privileged. E.g. sudo find . -exec /bin/sh \; -quit
That said, providing privileges to common users is not an easy thing to maintain and keep track of. Have a look at the GTFObins project in order to understand the full potential to escalate privileges.
Would a sane precaution be to add an environment variable like “SHELL=/bin/false” to any command to prevent allowing the user to gain a subshell?
Hi Travis
Nice idea, this sounds useful at the first glance but let’s have a deeper look into it.
Idea
To repeat the general idea: If the SHELL variable is set to /bin/false, it’s not possible to spawn a new shell:
So, this looks promising.
Sudo configuration not possible
Let’s try to add this to the command in the sudo configuration:
This is no valid sudo configuration:
So, it's not possible to add an environment variable by putting it before a command.
There would be an option so it is added via an environment file.
Create a new environment file with SHELL=/bin/false:
Add it to the sudo configuration:
This variable is not set after the login:
This is because sudo sets the SHELL variable according to the configured shell in /etc/passwd.
And when the shell in /etc/passwd would be changed, the user could not login anymore and use the sudo command to execute allowed commands. So this is no option.
Command Execution without Subshell
Another important point is that there are commands which can execute other commands without starting a new subshell.
Configure the SHELL variable to deny subshells:
It's not possible to start a subshell (as you expected):
However, it's still possible to execute commands that execute other commands:
So even if it would be possible to set environment variables for single commands (like SHELL=/bin/false), it would not prevent command execution from arbitrary files via sudo, because not always a new subshell is started.
I hope this answers your question. Let me know if you have other inputs on this ;-).
Best wishes,
Emanuel