Posts filed under 'PHP'
In Plesk, you can disable on a per-domain basis PHP’s safe_mode. Before doing this though, be advised that disabling safe_mode could lead to security risks for all of your domains on the server.
On the following steps, replace to your domain as needed.
To configure safe_mode usage, edit or create the file:
/home/httpd/vhosts/<domain-name>/conf/vhost.conf
The contents of the file should be something like:
<Directory /var/www/vhosts/<domain-name>/httpdocs>
Options +FollowSymLinks
<IfModule sapi_apache2.c>
php_admin_flag safe_mode Off
</IfModule>
</Directory>
Note that you can not edit /home/httpd/vhosts//conf/httpd.include as it overwritten by Plesk so all your changes would be lost if put there.
For the changes to take effect, you need to run the following:
/usr/local/psa/admin/sbin/websrvmng --reconfigure-vhost --vhost-name=<domain_name>
And then, reload Apache’s configuration with:
service httpd reload
Tested under Plesk 7.5.4.
January 17th, 2007
Running a check on Apache’s default logs (/var/log/httpd/access_log), I found attempts to exploit the server thru a “backdoor” in Horde.
I haven’t fully checked what could be done with this exploit but certainly leaving the affected script unprotected is an open invitation for trouble.
To check it, just request the following to any webmail domain on your server (the following check if completely harmless as it will only run uname -a and show it’s results on the browser):
http://webmail.yourserver.com///horde//services/help/index.php?show=about&module=;%22.passthru(%22uname%20-a%22);’.
With some imagination and careful URL encoding, you can get commands to be executed under Apache’s account and privileges.
What I’ve done until further investigation is performed, is to modify the affected script so that nothing happens when the script is called (so far seems like the only downside is Horde’s Help system not working).
The affected script is index.php, located at /usr/share/psa-horde/services/help.
For some debugging, I’ve included the following code right before Horde’s code:
<?php
$request = print_r($_REQUEST, true);
$server = print_r($_SERVER, true);
mail("youremailaddress@example.com", "HORDE BOGUS REQUEST ".date("r"), "Requestn".$request."Servern$server", "From: "Server" <youremailaddress@example.com>");
die();
?>
That will send you by email any requests with headers to the script, be those legitimate or attempts to exploit your server.
I will update the topic as soon as I have time to correct the script.
This was verified with psa-horde-3.0.5-rhel4.build75050824.12.
UPDATE: The problem is solved on Plesk’s 7.5.4 build 75060413.12, which includes psa-horde-3.1.1-rhel4.build75060413.11.
August 13th, 2006
When working with new programmers, and sometimes even experienced ones, I found that most of the time they would know how to solve a problem and code its solution but they wouldn’t be aware of security related implications. In this article, I’ll show how to improve security on PHP forms that use mail().
For a very simple Web site, a common usage of PHP is to create a contact form that will received visitor’s information and send it thru mail to the responsible of the Web site. The solution to this task is quite easy: create a form on HTML which will do a POST of the fields to a PHP script, and on the script use PHP’s mail() function to send the email with the provided information. If you want to have a more flexible solution, you could even receive on the script the recipient’s address, subject or some headers for the message.
Well, before going ahead and creating this simple form submission script (or you already have placed already on a Web site?), note that the script might be subject to a exploit which will allow spammers to send hundreds or thousands of messages without you being aware of it!. Please also note that even a proper anti-relay configuration of your MTA will not solve this problem since the messages are in fact valid locally-generated messages.
What happens is that a spammer, after some examination of your form’s fields, will prepare a POST request that contains specially crafted fields that will include new recipients (this process is called injection and is not limited to mail()). How is this possible? For this particular case, the spammer will include new “valid headers” on the POST that will trick mail() to send the message as Cc: or Bcc: with the victim’s addresses as new lines on the POST (separated with LF – line feed). The spammer could also include different MIME sections to hide the original form submission data and show only his message on the victim’s email agent.
Here’s a sample of how our message’s content would look like after being prepared by a spammer:
[XX-remitente_email] => namin
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Subject: a quarter past twelve and
bcc: batts1005@example.com
0e572d2671fa1c41bfcb3c522f68738a
.
With XX-remitente_email passed to mail() as the body, an email originated on your server would be sent to batts1005@example.com.
The solution? Sanitize all the received data that is going to be used as mail()’s parameters, stripping away all the LF and CR characters that appear on the data:
Original code
<?php
if (mail($recipient, $subject, $_POST['body'], "From: " . $_POST['mail'] . "\r\nReply-To: " . $_POST['mail'])) {
$sent = true;
} else {
$sent = false;
}
?>
Sanitized code
<?php
$_POST['body'] = stripCRLF($_POST['body']);
$_POST['mail'] = stripCRLF($_POST['mail']);
if (mail($recipient, $subject, $_POST['body'], "From: " . $_POST['mail'] . "\r\nReply-To: " . $_POST['mail'])) {
$sent = true;
} else {
$sent = false;
}
function stripCRLF($param) {
$param = preg_replace("/\r/", "", $param);
$param = preg_replace("/\n/", "", $param);
return $param;
}
?>
While programming Web applications, it is always a good practice to never trust the input from a visitor as a parameter for a procedure, function or query since it could be a specially crafted value trying to take advantage of a weakness or bug, either on your code or on the language’s native functions. One should always filter and validate all the raw data received from any Internet user that is going to be used somehow in our code.
The same considerations should be applied to any data used in SQL queries, system calls which use visitor’s input as parameters and variables that could be used without being previously declared or sanitized.
More information
June 18th, 2006
While I was designing a system that needed to send mass-customized emails from PHP, I faced two problems: a) change the envelope address (Return-path: header) and b) (most important) avoid overloading the server when sending the messages because of virus check.
Basically, I wanted to use a different sendmail configuration file from PHP to skip the relay-mail virus check from Amavis.
Please note that this script is to be called by a cron job as root to limit the number of messages sent on a batch; when getting the records from a database and sending the mails it’s quite easy to overload the server and get sendmail to stop accepting messages/connections.
Add the necessary logic to perform any additional checks, get the DB records and customize the content of the message accordingly.
This is the base code that will allow you to use a different sendmail configuration file:
<?php
$messg = "Here we put the content of the message.";
$sender = "email@example.com";
$sendmail = "/usr/sbin/sendmail -t -f $sender -C /etc/sendmail.nocheck.cf";
/*
Notice that sendmail is receiving three params:
-t Scan the To:, Cc:, and Bcc: from the message itself
-f Change the envelope (Return-path:) of the message
-C Use a different configuration file for sendmail, in this case the config file
skips the virus check
*/
$fd = popen($sendmail, "w");
fputs($fd, "To: recipient@example.comrn");
fputs($fd, "From: "Sender Name" <$sender>rn");
fputs($fd, "Subject: Finallyrn");
fputs($fd, "X-Mailer: Mailer Namernrn");
fputs($fd, $body);
pclose($fd);
?>
June 17th, 2006