Take the 2-minute tour ×
Information Security Stack Exchange is a question and answer site for Information security professionals. It's 100% free, no registration required.

Recent version of PHP 5.3.9 has been released a couple days ago, and Hash Collisions have been fixed, most of the servers actually didn't upgrade their server until now, including my website's server.
In this article I came across a part that has been told sites that are in a shared hosting can't upgrade their PHP by their own I know about that, but I'm wondering isn't that possible to use ini_set to set max_input_vars to secure your site (not server)?
I know that if someone attacks to the server the whole site will be down, but by setting the max_input_vars at least my site will be safe if somebody attack my site. Is this correct?

share|improve this question

2 Answers 2

Interesting article (CVE-2011-4885 for those who like references), thanks for the heads up - I'll be reading up on this but a few points stand out already.

  • just to clarify - the problem is within the logic tier - not the webserver itself.
  • your question of whether it is possible to use ini_set is predicated on the underlying PHP engine having been upgraded - when you've already argued that this is unlikely to happen for a lot of hosting providers. OTOH any hosting provider who does upgrade their PHP is likely to deploy the related ini changes or provide a mechanism for doing so.
  • while most hosting companies will actively avoid imposing a major upgrade on their users, they should be deploying vendor patches to existing deployments - and this patch has already been backported to all production versions of 5.3 and 5.2, I believe that Redhat have now released patches for current RHEL
  • there are at least 4 different places ini settings can be changed in PHP - in the php.ini file, in the webserver config (when PHP is implemented as a module), in .htaccess files (again if module) and in the PHP code itself - but not all setings can be changed in all places - so far the new config var is not in the manual to say where it can be changed.
  • in order to exploit this vulnerability, it would be necessary to send a significant amount of variables in the request - Apache (and probably most other webservers) allows some control over the total size of the request, request body, and POST data - also execution time - effective and selective use of these config options in both the httpd config and for specific directory trees using .htaccess could be used to mitigate any potential attack - bearing in mind any need to support (e.g.) file uploads.
  • the nature of a DOS based on this vulnerability is, in effect, very similar to the problem with range requests on Apache (CVE-2011-3192) - although a serious vulnerability, I've not seen much evidence of that defect being widely exploited.

I know that if someone attacks to the server the whole site will be down, but by setting the max_input_vars at least my site will be safe if somebody attack my site

I don't understand - certainly an attack based on this vulnerability will not result in leakage nor modification of data / code (AFAICS).

share|improve this answer
    
In the last part I didn't mean data modification by an attacker, I mean I myself change the setting in my project to prevent from DoS attacks, assume my server has been upgraded, but the default is 1000 and I can change max_input_vars, you're upvoted thanks. –  Sheriff Jan 14 '12 at 3:03

I know that if someone attacks to the server the whole site will be down, but by setting the max_input_vars at least my site will be safe if somebody attack my site. Is this correct?

I'd argue that unless max_input_vars is lower than the default (1000), it can still happen with multiple requests, you'd pretty much want to set this to the maximum number of vars your software uses, but what a pain to find out (or impossible if you have dynamic fields).

IMO: Band-aid on a cancer, they need to change the hash algorithm to be random.

share|improve this answer
    
How correct you are as to the "band-aid on cancer". The first fix on several php applications is to set max_input_vars to some unreasonably high number. Yes, we are dealing with that huge amount of data being transferred in the admin section of our app. In reality, there needs to be a public side with the limit and a trusted admin side with no limits. –  Fiasco Labs Apr 15 '12 at 17:09

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.