funkatron.com

I just checked in a bunch of bug fixes that get the security module of Zend_Environment working properly.

If you want to try it yourself, you’ll need to:

• Check out the latest Zend Framework from SVN
• Add the library and incubator/library directories from the SVN checkout to your include path
• Do some code-foo like this:

  require 'Zend.php';
  function __autoload($class) {
      Zend::loadClass($class);
  }
  
  $sec = new Zend_Environment_Module_Security('sec');
  $ze = new Zend_Environment(array($sec));
  echo $ze->toHtml();

There’s a lot more you can do with the Zend_Environment package that’s all due to Simon Mundy’s kickass work (more modules, you can iterate over results, query for settings, etc). I’ll try to cover some other usage scenarios in upcoming posts.

Terry Chay: My data in a box

The newest version of PHPSecInfo, version 0.2, is now available. Here are the major changes:

• Added link to “more info” in output. These lead to pages on the phpsec.org site giving more details on the test and what to do if you have a problem
• Modified CSS to improve readability and avoid license issue with PHP (the old CSS was derived from the output of phpinfo())
• New test: PhpSecInfo_Test_Session_Save_Path
• Added display of “current” and “recommended” settings in test result output
• Various minor changes and bug fixes; see the CHANGELOG for details

-Download now

-Join the mailing list

I just posted this to the phpsecinfo mailing list:

Folks who download today’s Zend Framework 0.8 release will notice the a new library in the “incubator” section: Simon Mundy’s Zend_Environment. People who look closer will notice that there is a “security” module for Zend_Environment, and a test framework called Zend_Environment_Security_Test that looks a lot like PhpSecInfo. Zend_Environment_Security is basically a port of the tests I’ve written for PhpSecInfo to work with Simon’s Zend_Environment module. It does *not* replace PhpSecInfo, but rather provide a similar testing capability built into the ZFW core. PhpSecInfo could be described as the “parent” project, with Zend_Environment_Security being based on the work I do in PSI. PSI is *definitely* the core, and will for the foreseeable future take priority over any “sibling” projects. Why did I only refer to my work on PSI, and not the other very helpful folks who have contributed? Because I cannot convert any contributed code from PSI unless the contributors have signed the ZFW Contributor License Agreement. For this reason, a few tests that are present in PhpSecInfo don’t have equivalents in Zend_Environment_Security. If you have contributed tests to PhpSecInfo, or plan on doing so, I’d like you to give serious consideration to signing the Zend CLA. It won’t put any additional burden on you, as I’ll take care of porting contributed tests to the Zend_Environment_Security model. - Zend Contributor License Agreement Note that I will *not* require PhpSecInfo contributors to sign the Zend CLA. If you choose not to do so, I will be happy to use your work in PhpSecInfo. I hope this clears up any confusion. If you have questions, please let me know.

For the past few years, PHP security experts have been pounding on the heads of sysadmins to turn off register_globals. While default installs of PHP turn it off, some popular web apps (especially older versions) insist on using it, so some webhost sysadmins will turn it on, presumably to make things go smoothly for their customers. Oops!

CVE-2007-0233, what seems like the 300th Wordpress vulnerability in the last two weeks, reports an sql injection vulnerability in Wordpress 2.0.6 (which was only released 11 days ago). The exploit appears to rely on register_globals being enabled, though:

funkatron@foo > php xpl.php foo.com /wp/

---------------------------------------------------------------------------
Wordpress < = 2.0.6 wp-trackback.php Zend_Hash_Del_Key_Or_Index /
/ sql injection admin hash disclosure exploit
(needs register_globals=on, 4 <= PHP < 4.4.3,< 5.1.4)
by rgod
dork: "is proudly powered by WordPress"
mail: retrog at alice dot it
site: http://retrogod.altervista.org
---------------------------------------------------------------------------

pwd hash   ->
admin user ->
exploit failed...

This is a good example of why web app security (and any security, for that matter) must be multilayered: on the hardware level, on the server daemon level, on the language environment level, and on the code level.

So, for the love of god, STOP ENABLING REGISTER_GLOBALS, upgrade to Wordpress 2.0.7, and (shameless plug) use PhpSecInfo to audit your PHP environment. ;)