A security hole has been found in Composr. This is a serious vulnerability that affects all versions of Composr 10+, and relates to our use of the PHP serialize function.

(It is not known to affect ocPortal websites)

It is critical that you deploy a resolution to this vulnerability as soon as possible.

Available resolutions

Upgrade Composr

Version 10.0.26 has been released and fixes the security hole.

Manually patch your site (for expert users who don't want to upgrade)

A patch file is attached if you wish to manually patch your code.
You can apply just the change to the secure_serialized_data function in sources/global3.php initially, although the whole patch is strongly recommended for safety. If a file referenced in the patch doesn't exist in your site, ignore that file (as it will be from an addon you do not have installed).

composr-security-vulnerability-fix-may-2019.diff

(or GitHub commit, which also makes corresponding changes in some development addons)

Checking for exploit attempts

To see if anyone has been trying to exploit the vulnerability, check your web server access logs for code_to_preexecute.
We have checked to ensure that the compo.sr server has not been breached.

Technical explanation

The PHP serialize function is known to be insecure for data transmission, because PHP objects with executable code can be buried inside serialized data. We have our own function secure_serialized_data which works around the insecurity by pre-filtering out any objects that Composr could automatically execute. This works for normal serialized data, but a small manipulation in the serialization format has been discovered that can bypass our filter.

In the ideal world we would not use serialize. However, we support PHP 5.1, which doesn't have JSON support, and JSON is the recommended replacement.

PHP 5.1 is no longer secure for numerous reasons, and has no support from the developers of PHP. However, many PHP webhosts do not update their PHP versions, or they run on distributions where vendors (e.g. Red Hat) manually patch older PHP versions to keep them alive artifically long. We have traditionally supported older versions of PHP because users of the hosting sometimes have no say, and moving hosting is disruptive and outside the skill-set of some users.

How the patch works

The patch fixes the vulnerability twice:

1. Fixes the issue in secure_serialized_data
2. Updates our use of PHP's unserialize function to disable classes (only works with PHP 7+)

Lessons learned

Any security vulnerability is humbling, and makes us reflect on how we can do a better job ensuring security in Composr.

Here are some key lessons from this vulnerability:

1. In the future our policy of supporting older PHP versions is changing: we will not be supporting any versions of PHP that are not supported by the PHP developers. We should not artifically insulate users from the problems running old PHP versions, and we should work as a part of the broader PHP community in advancing progress rather than holding back. Any agent encouraging users to be running old versions (e.g. webhosts) needs to be leaned on to not do that.
2. Trying to patch a well-known vulnerability area by 'cleverness' is rarely a good idea. We will migrate to JSON properly for v11. We could have even done it in v10 without dropping PHP 5.1 support if we pulled in a 3rd-party JSON implementation to do it – the only reason this was not done is time constraints.
3. The vulnerability was privately reported to us, and took some time to fix as it involved changes across our code, and consideration of what to do on future versions, and if it affects the APIs on the compo.sr server. Only Chris could look into this, and he was just starting a big house move (that proved particularly troublesome) as the vulnerability was reported privately to us. It is important in the future to diversify the development team and expertise so that nothing depends on any one person and fixes can be made within days not weeks. This will be a key part of our upcoming project relaunch.

Credit

Currently we don't have a name to credit this vulnerability against. When white-hack hackers work with us to disclose vulnerabilities in a responsible way, we like to credit them for it. Their work helps keep Composr secure, because it is always possible someone malicious could have found the vulnerability instead.