[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <CAKws9z3xksc=cvW-Zm==jfUZOX1zyNEeC7OZ4BSXXQ54d=1F5w@mail.gmail.com>
Date: Tue, 22 Nov 2016 10:17:24 -0500
From: Scott Arciszewski <scott@...agonie.com>
To: oss-security@...ts.openwall.com
Subject: Re: WordPress (all versions): SPOF, RCE, and Negligence
On Tue, Nov 22, 2016 at 5:13 AM, Hanno Böck <hanno@...eck.de> wrote:
> Hi,
>
> Sorry, but I find a lot of your statements very questionable.
>
> On Mon, 21 Nov 2016 11:54:33 -0500
> Scott Arciszewski <scott@...agonie.com> wrote:
>
>> Consequently, the WordPress update server is one of the largest single
>> points of failure (SPOF) on the Internet.
>
> Yeah, just like the update servers from Microsoft (which are definitely
> a bigger POF). Or Apple. Or Google. Or Samsung. Or Mozilla.
>
> Granted, having signatures as an additional protection on top of TLS
> improves security, but it's an unfortunate fact that update
> infrastructure is a big attack surface and a complicated problem.
> Signatures can only change a single point of failure to two points of
> failure.
> The solution is probably something along the lines of transparency logs
> and for binary software reproducible builds, but nobody has anything in
> that space that works today.
>
> Wordpress could do better in terms of security with some issues, e.g. I
> find it disappointing that they don't seem to show any interest in
> deploying CSP.
> But the fact that Wordpress has auto updates at all imho puts it
> in front of every other CMS out there in terms of security.
> For all the others they basically expect their users to manually
> install updates, sometimes within hours as could've been seen with
> every RCE in joomla or drupal that was discovered in the past.
> Wordpress having an auto update has probably protected millions of
> webpages from being compromised.
>
>
>
> --
> Hanno Böck
> https://hboeck.de/
>
> mail/jabber: hanno@...eck.de
> GPG: FE73757FA60E4E21B937579FA5880072BBB51E42
Hi Hanno,
I'm glad you brought these points up. The subject of secure code
delivery is a thorny problem that I've thought about a lot, and I'm
glad to hear similar issues from cryptography researchers --
especially ones whom I respect.
> Granted, having signatures as an additional protection on top of TLS
> improves security, but it's an unfortunate fact that update
> infrastructure is a big attack surface and a complicated problem.
> Signatures can only change a single point of failure to two points of
> failure.
Quick aside: From
https://paragonie.com/blog/2016/10/guide-automatic-security-updates-for-php-developers#elements-automatic-updates
(linked in my initial email), I outlined the elements of a secure
automatic update system. They are (for the sake of permanent record
here)...
1. Offline Cryptographic Signatures
2. Reproducible Builds
3. Decentralized Authenticity / Userbase Consistency Verification
4. Transport-Layer Security
5. Mirrors and Other Availability Concerns
6. Separation of Privileges
I'm fully in agreement that offline signatures alone are not enough.
However, it's the most straightforward addition to their protocol to
satisfy one of these requirements.
> The solution is probably something along the lines of transparency logs
> and for binary software reproducible builds, but nobody has anything in
> that space that works today.
Binary software reproducible builds isn't entirely relevant to PHP
development (the closest we have to a binary is a PHP Archive, or
Phar), but on the note of "nobody has anything in that space that
works today", see:
* https://paragonie.com/blog/2016/05/keyggdrasil-continuum-cryptography-powering-cms-airship
* https://paragonie.com/project/pharaoh
I apologize if anything I said in my initial email implied that
signatures were enough. They're just the first step towards a
resilient solution.
With respect,
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.
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
