Compass Security Blog

Offensive Defense

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:


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
*       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:
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:


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


  1. 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 *..*

  2. 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/*[ ]*
    hacker10 ALL= (root) !/bin/less /var/log/*[[\:blank\:]]*

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

Leave a Reply

Your email address will not be published. Required fields are marked *