Date: Mon, 21 Nov 2016 22:13:37 +0100 From: Solar Designer <solar@...nwall.com> To: oss-security@...ts.openwall.com Subject: Re: WordPress (all versions): SPOF, RCE, and Negligence Scott, I'm normally not into rants, and am unlikely to continue beyond this reply (unless there's something I'll need to clarify), but I thought I'd share a different perspective: On Mon, Nov 21, 2016 at 02:24:40PM -0500, Scott Arciszewski wrote: > 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. Or rather, get a lot of people to stop updating their WordPress installs. WP already sort of did that (but not to the exact same group, although there's overlap) by making their update server meet modern TLS protocol/ciphersuite guidelines, which locked some older servers out of updates. So much for security, and due to the pressure we, the security community, are putting on everyone on the web to upgrade ASAP because of oh so dangerous flaws in SSL/TLS protocols. Meanwhile, the reality is that SSL/TLS protocol flaws are irrelevant to almost all actual WP install compromises, whereas out-of-date plugins are relevant. (OK, that's usually not core WP code anyway, and would probably be out-of-date on those installs anyway. Not that it makes your point stronger, but it does make mine weaker.) > 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 While moving to native PHP 5.5+ APIs would be very nice if affordable, I think it very well might not be affordable for WP yet. If so, I think WP should in fact start using bcrypt hashes by default on systems that certainly have support (PHP 5.3.7+), but also support the existing phpass hashes that might already be in databases, as well as if WP happens to be installed on older PHP. (This is what I had recommended from the start, but I understand it didn't work for them before.) This would break only downgrades from PHP 5.3.x+ to 5.2.x, which I hope is affordable for them to do by now. The comment you link to where they discussed this very issue is from 4 years ago. Hopefully, the decision can be different now: support those older systems, but not downgrades. Something I am not familiar with, though, is exactly how bad the PHP vulnerabilities fixed since 5.3.x are. If they can be used to fully compromise WP installs despite of reasonable(?) defensive programming and workarounds, then there's not much choice but to insist on newer versions now. It's just that from actual in the wild compromises this doesn't appear to be the case. A reason I am skeptical about most upgrades is that we're not replacing something broken with something non-broken. We're replacing some known and some unknown issues with possibly even more of yet unknown issues. Sure, there are also clear moves in the right direction, such as bcrypt (which is mature and is in fact getting old) and better APIs and fixing of old bugs too, but there's also still a lot new that we'd likely find comparably ridiculous (as what we're replacing) if we took a closer look. For example, this was the case with the rushed move from CBC mode to RC4 a few years ago only to (re-)discover that RC4 is broken a year later. As far as I'm aware (and not being familiar with PHP, I might be wrong), PHP internals have not improved much if at all - only specific bugs have been addressed, and features and APIs added. I am for progress, and I have often been on your side - trying to convince a maintainer to make some upgrade to what's becoming the new norm - but I think the real-world effects of forcing things upon people are trickier than what you might expect. In the short term, WP requiring PHP 7+ or 5.6.x+ (the upstream supported versions) would be a problem, including for security (tricky to get newer libraries and languages onto older systems safely and keep them updated, as you point out below). Whether it would be a win in the longer term is unclear. I fully agree with you that updates must be signed. That's a very real issue. Now, this brings up the question on what a PHP app can/should use to verify signatures on updates. Is this something you blogged on, too, with specific suggestions? > There is a similar problem with Linux distributions shipping stale > versions of libsodium: > http://stackoverflow.com/questions/40684596/libsodium-for-php-is-not-working It's expected that many distros will have older versions of software. When dependency hell bites me, I usually mostly blame the software I am trying to build, and not the system providing older libraries. I know I can replace the system, but I'm usually on the older one by choice. My usual preference is older base system (let someone else deal with some of the the new bugs, potential malicious code, etc. first), but recent few pieces of software that I actually need to be recent. In a way, this is unfortunate, but it's a reality that software meant to be widely used should avoid external dependencies on anything recent except for things most essential to its operation. > 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. IMO, not wanting to have development tools in production is more of a custom and phobia than anything rational. Can have PHP but afraid to have gcc? (With lots of containers, pre-installed development tools can add up to significant size. But I think that wasn't your point.) The rational concerns here are that building libsodium from source might not be worth the time, and that the sysadmin building software in production may be a risk (more so than merely having development tools installed) - e.g., the person not verifying authenticity of downloads, build scripts creating files under /tmp unsafely, etc. In the example above with needing libsodium for Argon2, perhaps this wasn't worth the trouble for the person, who should have simply used bcrypt until versions of PHP with Argon2 (or whatever) built in become standard. You might want to re-word your blog post to de-emphasize the importance for most/smaller sites of going with Argon2 at this time. Alexander
Powered by blists - more mailing lists
Please check out the Open Source Software Security Wiki, which is counterpart to this mailing list.
Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.