Date: Mon, 21 Nov 2016 14:24:40 -0500 From: Scott Arciszewski <scott@...agonie.com> To: oss-security@...ts.openwall.com Subject: Re: WordPress (all versions): SPOF, RCE, and Negligence On Mon, Nov 21, 2016 at 11:32 AM, Ben Tasker <ben@...tasker.co.uk> wrote: > I assume you're talking about the PHP versions that Wordpress supports (as > opposed to on their update server?). Yes. Raise the minimum PHP version supported by WordPress and get everyone onto non-EOL'd versions of PHP. Among other benefits, you can then move every WordPress blog to use password_hash() and password_verify() instead of their current situation (i.e. 8192 rounds of salted MD5 for password storage). I'm not kidding. https://paragonie.com/blog/2016/08/on-insecurity-popular-open-source-php-cms-platforms#wordpress-password-storage On Mon, Nov 21, 2016 at 1:26 PM, Michael Babker <michael.babker@...il.com> wrote: > On Mon, Nov 21, 2016 at 11:32 AM, Ben Tasker <ben@...tasker.co.uk> wrote: > >> There was a similar issue a while back where Joomla! decided to run a >> version check to ensure PHP version was >= 5.3.10. It broke a number of >> sites, and the most common fix seems to have been a core-hack to disable >> that check. The logic for inserting that check was reasonable, but lacked >> consideration of who the market actually is. > > > While I can somewhat understand why the Linux distributions choose the > model they use for their "long term support" packages, it honestly does a > disservice to those of us who now have to defensively code around it. We > can no longer rely on a package's version to accurately represent the state > of the code base. > > I was Joomla's release lead at the time this decision was made. We did not > arbitrarily choose a PHP version number, arbitrarily locking out vendor > modified PHP builds distributed with the LTS distros, just because we > wanted to. We first attempted to implement bcrypt password hashing using > feature detection, after hacking the polyfill library to lower its PHP > minimum from 5.3.7 (which blocked some of its checks) to be able to try and > support the PHP 5.3.3 build the distros have elected to stabilize on and > modify. This effort failed catastrophically, and our project collectively > decided we could not revert support for bcrypt hashed passwords and could > not try to support this feature using feature detection mechanisms; it was > too unreliable and we elected therefore to lock on a version number which > we knew would satisfy all of our requirements natively. We could have > locked to 5.3.7 but elected to bump to 5.3.10 due to the security issues > fixed between those releases and at that point Ubuntu's LTS was at that > version so it helped us to make a logical choice. > > While I understand where you are coming from, to be quite frank, I don't > believe the PHP ecosystem and its major players can continue to cater to > these modified PHP builds as might have been expected in years past. There is a similar problem with Linux distributions shipping stale versions of libsodium: http://stackoverflow.com/questions/40684596/libsodium-for-php-is-not-working The only reliable workaround involves **installing gcc to production then compiling libsodium from source**. And then uninstalling gcc because you probably shouldn't have that installed in a production environment. Naturally, a lot of people don't feel comfortable with that. Linux distros that provide PHP 5.3, 5.4, or 5.5 are a problem, but they really shouldn't pin the patch number. Just pin the major and minor versions. Offer 5.6.x, not 5.6.28. For Debian users, Guillaume Pleissis does it right. Follow his example, please: https://www.dotdeb.org/2016/11/10/php-7-0-13-for-jessie/ Scott Arciszewski Chief Development Officer Paragon Initiative Enterprises <https://paragonie.com>
Powered by blists - more mailing lists
Please check out the Open Source Software Security Wiki, which is counterpart to this mailing list.
Powered by Openwall GNU/*/Linux - Powered by OpenVZ