The understanding of the systems architecture is essential to analize its security. PHP file upload architecture:

1. Files are transferred from client filesystem to server RAM.
2. Apache process will check httpd.conf and php.ini directives.
3. Once completed, file will be dumped into the server’s default temporary directory, unless another location has been given with the upload_tmp_dir directive in php.ini. The temporary directory used for storing files must be writable by apache user.
4. After a correct transfer, if track_vars is enabled (always since 4.0.3), $_FILES superglobal array is defined (is available in all scopes throughout a script. There is no need to do global $variable; to access it within functions or methods). Only name and type are provided by the user, and therefore tmp_name, error, and size are provided by PHP. The related variables will be initialized as globals if register_globals is enabled (must be desactivated).
5. The control is given to the php script to move the file to another location. If not, the temp file will be automatically unlinked at the end of the script.

• Directives in a php.ini file
  • upload_max_filesize = 10M
  • post_max_size = 20M
• .htaccess file
  • php_value upload_max_filesize 10M
  • php_value post_max_size 20M
  
  
  The PHP documentation states that the memory_limit setting also affects file uploading. Generally speaking, memory_limit should be larger than post_max_size.
  
  

  • memory_limit = 16M to your php.ini file (recommended, if you have access)

  With root access, you can use the sed util in Linux/Unix based systems, in order to increace the memory for 64M. Don’t forget to properly locate you php.ini file!

  sed -i 's/memory_limit = 16M/memory_limit = 64M/' /etc/php5/apache2/php.ini
  • ini_set('memory_limit', '16M'); to your sites/default/settings.php file
  • php_value memory_limit 16M to your .htaccess file in root

Ah it’s Wordpress again, sometimes I wonder how many holes there are in Wordpress. I guess a dedicated attacker could find some serious ones with the complexity of the code base.

It’s suspected some of the recent high profile breaches have come from Wordpress exploits.

The latest one to become public is a simple but effective flaw, it doesn’t enable take-over but it does allow a prankster to lock an admin out of their blog by resetting the password.

Developers of the widely used WordPress blogging software have released an update that fixes a vulnerability that let attackers take over accounts by resetting the administrator password.

The bug in version 2.8.3 is trivial to exploit remotely using nothing more than a web browser and a specially manipulated link. Typically, requests to reset a password are handled using a registered email address. Using the special URL, the old password is removed and a new one generated in its place with no confirmation required, according to this alert published on the Full-Disclosure mailing list.

The flaw lurks in some of the PHP code that fails to properly scrutinize user input when the password reset feature is invoked. Exploiting it is as easy is directing a web browser to a link that looks something like:

I actually saw the alert as it was published on Full-Disclosure, obviously anything to do with Wordpress catches my attention.

The exploit can be executed by running the following code on a Wordpress 2.8.3 blog:

http://www.domain.com/wp-login.php?action=rp&key[]=

Simple but effective.

According to WordPress documentation here, the bug has been fixed by changing a single line of code so the program checks to make sure the input supplied for the new password isn’t an array. If it is, the user gets an error message and must try again.

That would appear to be the end of it, but security researchers Rafal Los and Mike Bailey wonder aloud here whether it would have made more sense to check instead whether the input is a string.

“Hasty coding?” he asks. “Why take the blacklist vs. whitelist approach?”

The bigger point he and other observers seem to make is that PHP is the coding equivalent of an everyman’s jet pack. It allows him to quickly soar into the sky with a minimal amount of training but doesn’t necessarily provide the means to check for buildings, planes or other hazards that may greet the user once he gets there.

Wordpress 2.8.4 has already been released so if you’re running Wordpress do update ASAP to ensure you are safe from this bug.

With the core updates now available on auto-update there’s no excuse for not updating (no more download, extract, upload via FTP).

Of course with its history, this doesn’t mean you are safe from any of the other exploits that haven’t been made public.

Source: The Register

ShareThis

Tags:  exploits,  hacking-wordpress,  vulnerabilities,  Web Hacking,  web-application-security,  wordpress,  wordpress 2.8.3 exploit,  wordpress admin reset bug,  wordpress bug,  wordpress-exploit,  wordpress-security,  wordpress-vulnerability

Destacar la parte de

I’ve found that people who use WordPress want to work with people who use WordPress. They also want to play with them. Think of the possibilities of creating a special interest group on car racing, a sport, knitting, book reading, or whatever interest you have and/or blog about. Why not? I’d love to connect with people interested in what I’m interested in, learning from and with each other by a common bond.

El texto.

WordPress and WordPressMU Merged: Whoa!

http://carlosandrade.es/static/WP27b/nav.html?index.html

Espero que este bien cacheado en htaccess