How We Engineered CMS Airship to Be Simply Secure • Hacker News Board

Re: How We Engineered CMS Airship to Be Simply Secure

#21

Post by CiPHPerCoder » Sun, Mar 19, 2017, 5:37 PM UTC

xorraxrax wrote: post #16

My biggest problem with Paragon IE is the fact that its owner, Scott Arciszewski, continues trying to make it seem as though his company consists of anyone else other than just himself. From the kitschy redundant name (is it an Initiative or an Enterprise?) to the awful typography, web design and logos[1], to the fact that all of his blog posts and commits are anonymized as "P.I.E. staff", "paragonie-security"... The…

You are mistaken.

https://www.corporationwiki.com/p/2ixe71/paragon-initiative-...

That's all I will say about the matter.

Re: How We Engineered CMS Airship to Be Simply Secure

#22

Post by dang » Sun, Mar 19, 2017, 9:09 PM UTC

xorraxrax wrote: post #16

My biggest problem with Paragon IE is the fact that its owner, Scott Arciszewski, continues trying to make it seem as though his company consists of anyone else other than just himself. From the kitschy redundant name (is it an Initiative or an Enterprise?) to the awful typography, web design and logos[1], to the fact that all of his blog posts and commits are anonymized as "P.I.E. staff", "paragonie-security"... The…

This crosses into personal attack. We've banned accounts that do this, so have banned this one.

Re: How We Engineered CMS Airship to Be Simply Secure

#23

Post by orf » Sun, Mar 19, 2017, 9:57 PM UTC

CiPHPerCoder wrote: post #18

orf wrote: post #17

Earlier quoted context omitted.

> Those are all my research findings. :P Yes, and well done! But there are not many framework specific issues you've found. None in Laravel for example. Is your homemade framework superior to Laravel? If so, how? > Feel free to try to find an exploitable security hole. I can't be bothered to learn your home grown half framework so i understand the convoluted logic. That's the point. There are vulnerabilities in there…

> Is your homemade framework superior to Laravel? If so, how? Our cryptography is certainly superior to Laravel's. https://github.com/illuminate/encryption https://github.com/paragonie/halite Beyond that, nobody has paid me to look deeper and I haven't had any reason to. > There are vulnerabilities in there, I've seen enough code like that to almost guarantee you. If so, then anyone reading this thread who's aware of…

> Our cryptography is certainly superior to Laravel's...

Ok, but cryptography is only a small portion of what a framework does and not necessarily the most important bit. I was asking more about your routing, view layer, ORM, code layout, templating, validation, caching, ACLs etc.

> Beyond that, nobody has paid me to look deeper and I haven't had any reason to.

Look, you can't put up a blog post titled "How We Engineered CMS Airship to Be Simply Secure" and say that when asked "well, how did you actually engineer it to be secure?". In your post you talk about problems all solved by a framework, and apparently you haven't even evaluated what is out there already and rushed headfirst into building it all yourself.

This is not engineering a project to be "simply secure", in the sense that it is definitely not simple and probably not secure!

> If so, then anyone reading this thread who's aware of any vulnerabilities will be interested...

This is great! I wish more companies did this. However, as stated previously, the ad-hoc nature of the code and the single-developer nature[1] makes this pretty hard to do from a code review point of view. Again, using a framework makes your code way easier to review and a lot smaller to boot. Anyone with Django experience can pick up a Django app and start to review it, rather than have to learn whatever bespoke framework the developers of the project dreamed up.

Also I just wanted to add that I don't mean to come across as a dick, your project looks interesting for sure and a lot of work has gone into it. PHP CMS's need to start taking security seriously, things like Joomla and random Wordpress plugins are a blight and anything taking security seriously is great! As someone who works in the security industry it's just a bit tiring to see yet another homegrown PHP half-framework full of it's own intricacies and potential issues with the ever familiar problems described in all my comments above, coupled with a post saying how it was engineered to be secure from the ground up.

1. It's hard to tell, in this graph (https://github.com/paragonie/airship/graphs/contributors) is 'paragonie-security' a single person?

Re: How We Engineered CMS Airship to Be Simply Secure

#24

Post by CiPHPerCoder » Sun, Mar 19, 2017, 10:05 PM UTC

orf wrote: post #23

CiPHPerCoder wrote: post #18

Earlier quoted context omitted.

> Is your homemade framework superior to Laravel? If so, how? Our cryptography is certainly superior to Laravel's. https://github.com/illuminate/encryption https://github.com/paragonie/halite Beyond that, nobody has paid me to look deeper and I haven't had any reason to. > There are vulnerabilities in there, I've seen enough code like that to almost guarantee you. If so, then anyone reading this thread who's aware of…

> Our cryptography is certainly superior to Laravel's... Ok, but cryptography is only a small portion of what a framework does and not necessarily the most important bit. I was asking more about your routing, view layer, ORM, code layout, templating, validation, caching, ACLs etc. > Beyond that, nobody has paid me to look deeper and I haven't had any reason to. Look, you can't put up a blog post titled "How We Engine…

> Look, you can't put up a blog post titled "How We Engineered CMS Airship to Be Simply Secure" and say that when asked "well, how did you actually engineer it to be secure?". In your post you talk about problems all solved by a framework, and apparently you haven't even evaluated what is out there already and rushed headfirst into building it all yourself.

I've looked at Laravel, about two years ago. http://seclists.org/fulldisclosure/2015/Apr/57

I haven't looked deeper at what it's done since then, since nobody is paying me to do so. I wasn't impressed then, and instead of waiting for them to get around to doing things right (while figuring out how to preserve backward compatibility), I started from zero.

You don't have to like that decision, but that's the decision I made.

> Again, using a framework makes your code way easier to review and a lot smaller to boot.

Sure, use a framework.

And then this happens: https://kivikakk.ee/cryptography/2016/02/20/breaking-homegro...

I designed my own because, unfortunately, most of the PHP community either doesn't prioritize security enough to be trustworthy, or is simply in over their heads.

We use third party libraries (Twig for templates, HTML Purifier for allowing some HTML but avoiding XSS vulnerabilities) because they're well-studied and trustworthy libraries.

However, I do not trust most other PHP developers to do anything security-critical correctly. And thus, I will not design something meant to be secure based on an insecure foundation.

If your only reason for Airship's status as "probably insecure" is because it's "ad-hoc" and/or "bespoke": Sorry, that's insufficient. Got a PoC handy?

Otherwise: we're talking about pure hypotheticals that are far removed from the real world and there's not much point in that. You can frame your criticism as "things to make the code easier to read/understand" and whatnot, and they stand alone. Citing them as "probably a vulnerability" is questionable, however.

> It's hard to tell, in this graph (https://github.com/paragonie/airship/graphs/contributors) is 'paragonie-security' a single person?

For the moment, I'm the only technical person at Paragon. That will change, and that account will be delegated to signing/committing the code changes made by other employees.

> As someone who works in the security industry it's just a bit tiring to see yet another homegrown PHP half-framework full of it's own intricacies and potential issues with the ever familiar problems described in all my comments above, coupled with a post saying how it was engineered to be secure from the ground up.

You've raised legitimate concerns over:

  - Apparent NIH-syndrome, which in this case is justified
  - Minor code quality nits, which are now fixed
  - Bus factor

...but none of those are, directly, a security problem. :)

Re: How We Engineered CMS Airship to Be Simply Secure

#25

Post by theamk » Mon, Mar 20, 2017, 2:19 AM UTC

CiPHPerCoder wrote: post #20

theamk wrote: post #19

Earlier quoted context omitted.

I strongly disagree -- I think "self writing code" has the worst failure mode ever: any security vulnerability leads to permanent compromise which is persistent across versions and requires non-trivial skill even to detect. Because there will be security vulnerability, and people will be exploited, and even if your update system runs every 4 hours, it will take dev team some time to write up a fix and push an update.…

> I strongly disagree -- I think "self writing code" has the worst failure mode ever: any security vulnerability leads to permanent compromise which is persistent across versions and requires non-trivial skill even to detect. The auto-updater does nothing to make this worse. That's true of any vulnerable system. Once you're owned, you're owned. > Because there will be security vulnerability, and people will be exploi…

> The auto-updater does nothing to make this worse. That's true of any vulnerable system. Once you're owned, you're owned.

No. If you have RCE in the regular app, the attacker cannot make attack 'stick'. Once you reboot the machine, or restart service (in case of systemd), any malicious code no longer runs.

Now, if there is a privilege escalation bug the situation will get worse, but having 2 unpatched bugs is significantly less likely. Of course, you want to make sure unattended updates are enabled so your host OS is up to date.

As a result, most other systems will actually self-heal from minor compromises. Only your system (any many other PHP systems in general) will stay compromised forever.

> It runs every 15 minutes, in the default configuration, and our usual turnaround time for getting a bugfix out is less than 1 hour.

1 hour from what? From someone sending email to your team? If a black hat finds an exploit in your service, they will start compromizing the existing web servers first. You will not find out about the bug until someone notices something weird on their installation, and that will take way more than an hour.

> 2. Don't chown/chmod.

Have you actually tried this? Looking at your github, there seems to be `src/tmp/cache` directory -- presumably at least this one should be chmod'ed? What about others? What about plugins -- would they work fine without writeable root?

I have tried to make other PHP packages use immutable code, and it was very flaky and painful. You need to structure your program in a certain way to make sure it works with immutable root -- one location for temp, another for configs, third for the code. If your main development team uses writable code, there is a high chance immutable code would not work well.

> It's not broken, it's a trade-off. Nothing to fix.

> The reason we do this by default is because our threat model is ensuring automatic updates work for everyone (including people who are not sophisticated enough to set up a cronjob).

Why do you say it's hard to set up a cronjob? It is simple -- your deb/rpm package just includes file /etc/cron.d/aristrip, and voila -- you are done. The only place where cronjob setup is hard is on these cheap shared PHP hosting services. And I think no one should be using them -- get a $5 Linode VM instead.

The thing is, the modern Linux systems went pretty far in terms of security and isolation. You have multiple easy-to-use technologies for threat protection -- docker, Apparmor, capabilities, systemd' *Path, etc.. They work pretty well to make sure that attacker which got RCE cannot take a hold on a system and elevate privileges.

Except your system is not compatible with any of them, by design. Because you don't care. Maybe you should change your motto from "A Secure Content Management System for the Modern Web" to "A Secure Content Management System for the Cheap Shared PHP Hosting", because you can certainly do much better for the modern web.