Dangerous Sudoers Entries – PART 5: Recapitulation

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:

Define the allowed “sudo” commands carefully. Don’t allow commands to be run without knowing all the features it offers.

1. Disallow the execution of further commands by adding the “NOEXEC” flag:

hacker10 ALL= (root) NOEXEC: /bin/less /var/log/*

2. Check if the feature set of the command can be restricted. E.g. check for environment variables shown “LESSSECURE=1” for “less”:

#/etc/profile.d/lesssecure.sh
LESSSECURE=1
readonly LESSSECURE
export LESSSECURE
#/etc/sudoers
Defaults        env_reset, env_keep=LESSSECURE

3. Check the file permissions carefully as this might render all your efforts useless:


4. Only use wildcards when you know that a breakout will be impossible.

The first example shows how to access the “/etc/passwd” file directly:

The second example shows how to open an additional file which can later be accessed by typing “:n” in “less”:

By following these rules you might avoid a malicious user to gain further privileges on your system.

 

Dangerous Sudoers Entries – PART 4: Wildcards

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:

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”.

Dangerous Sudoers Entries – PART 3: Permissions

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:

Another pitfall of securing “sudo” commands are the file system permissions. If the permissions aren’t set correctly, an attacker might circumvent the restrictions we have implemented during the last two blog posts. For the next example the administrator changed the directory permissions for the directory “/var/log/” to “777”. Obviously, this is a bad idea for this directory and a almost unrealistic scenario. None the less, this situation might appear if we use an application specific directory which has been configured manually.

Because of the write permissions in this directory we are allowed to create arbitrary files in it. This allows us to create links to files residing in other directories. This will grant us access to the linked file once we use “less” as user root:

“less” shows us the following content when the previous command is executed:

Furthermore, ensure that the user has no write permissions on the executable.

Solution

The only solution to this issue is setting appropriate permissions on the file system!

Dangerous Sudoers Entries – PART 2: Insecure Functionality

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:

In this article we are going to focus on insecure functionality “less” offers. The example with “less” is just to illustrate that the functionality of each application we use with “sudo” has to be checked carefully to ensure that a malicious user won’t be able to abuse it.

“less” offers a command to read other files on the system. Again, the current permissions of “less” are used to read these files.

Excerpt from the man page:

:e [filename]

Examine a new file. If the filename is missing, the "current" file
(see the :n and :p commands below) from the list of files in the
command line is re-examined. A percent sign (%) in the filename
is replaced by the name of the current file. A pound sign (#) is
replaced by the name of the previously examined file. However, two
consecutive percent signs are simply replaced with a single percent
sign. This allows you to enter a filename that contains a percent
sign in the name. Similarly, two consecutive pound signs are
replaced with a single pound sign. The filename is inserted into
the command line list of files so that it can be seen by subsequent
:n and :p commands. If the filename consists of several files, they
are all inserted into the list of files and the first one is
examined. If the filename contains one or more spaces, the entire
filename should be enclosed in double quotes (also see the -"
option).

In the following example the /etc/shadow file has been read.

Solution

The environment variable “LESSSECURE” can be set to “1” to disable dangerous features of “less”.

Excerpt from the man pages:

When the environment variable LESSSECURE is set to 1, less
runs in a "secure" mode. This means these features are disabled:
!      the shell command
|      the pipe command
:e     the examine command.
v      the editing command
s -o  log files
-k     use of lesskey files
-t     use of tags files
metacharacters in filenames, such as *
filename completion (TAB, ^L)
Less can also be compiled to be permanently in "secure" mode.

There are now two steps we have to take to ensure that this works as expected. First, the current user must have the “LESSSECURE” environment variable set as read-only. Otherwise the user would be able to change its value. This can be achieved by adding the following line to a file in the path “/etc/profile.d/”. We use a new file called “/etc/profile.d/lesssecure.sh” and add the following content:

LESSSECURE=1
readonly LESSSECURE
export LESSSECURE

The second step is to tell “sudo” to keep the “LESSSECURE” variable from the user. This is achieved by adding the env_keep option in the sudoer’s file:

Defaults        env_reset, env_keep=LESSSECURE

The following message appears now if someone tries to use one of the insecure commands.

Dangerous Sudoers Entries – PART 1: Command Execution

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:

In this article we are going to focus on the command execution feature of “less” which may appear in other applications and scenarios as well. “less” allows a user to execute arbitrary commands by entering “!”.

Excerpt from the less man page:

! shell-command

Invokes a shell to run the shell-command given. A percent sign (%)
in the command is replaced by the name of the current file. A
pound sign (#) is replaced by the name of the previously examined
file. "!!" repeats the last shell command. "!" with no shell 
command simply invokes a shell. On Unix systems, the shell is
taken from the environment variable SHELL, or defaults to "sh".
On MS-DOS and OS/2 systems, the shell is the normal command
processor.

As an example, we run the command “whoami” within “less”:

This command is being executed with the same rights “less” is running. Therefore, whoever is allowed to read a file with less is allowed to execute commands with the same rights. In this case as the user “root”.

Another feature that falls in the category command execution is the possibility to start the default text editor as this is nothing else but the execution of another application. To start the default text editor the user has to press the “v” key.

Excerpt from the man page:

v      Invokes an editor to edit the current file being
viewed. The editor is taken from the environment variable VISUAL
if defined, or EDITOR if VISUAL is not defined, or defaults to
"vi" if neither VISUAL nor EDITOR is defined. See also the
discussion of LESSEDIT under the section on PROMPTS below.

In our case we start the editor “nano” from “less”:

Of course it is possible to prevent “less” from executing arbitrary commands. There are two possible ways to do this. The one described in this part of the blog post focuses on the general prevention of additional command execution and isn’t “less” specific. Therefore, it is possible to use this solution for other applications as well.

Solution

The execution of other binaries might be prevented by adding the NOEXEC tag in the sudoer’s file. This works only if “sudo” has been compiled with noexec support and if the underlaying OS supports this as well.

hacker10 ALL= (root) NOEXEC: /bin/less /var/log/*

The following two screenshots shows the results of the previously described methods to run an arbitrary command or default editor.