[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
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.
