6 ms·

CMS Airship - Simply Secure Content Management

14 points by CiPHPerCoder 10y ago

Flimm 10y ago
Yes! It's about CMS's compete a bit on security. Content Security Policy needs to be by default. This page says CSP is managed "through a web interface", which worries me a bit.
- CiPHPerCoder 10y ago
  > This page says CSP is managed "through a web interface", which worries me a bit. Administrators can update a JSON file that is used by CSP-Builder to generate the Content-Security-Policy headers. We wanted to normalize this browser securtiy feature and make it user friendly for users to manage these headers.
CiPHPerCoder 10y ago
> Never again worry about zero-days. Before anyone asks, the point of this statement isn't "We'll never have a security hole." It's "the time-scale that the patch will be released and applied is less than one hour, not multiple days". An alternative way of putting it might be: Zero hours are the new zero days.
- barkingcat 10y ago
  Maybe reword that phrasing a bit then to make it mean what you want? As a server operator I will always be worried about zero days, regardless of what my cms is or who wrote the software. The person who stops worrying about it is the one who will get hacked. Maybe you mean "stop waiting for vendors to patch zero days?" And even then, once a zero-day hits, someone's going to have to write that patch, and if it's in a base library like openSSL it can be non-trivial, and you're going to have to wait regardless of what CMS you choose. Either way, the wording needs to be refined.
  - CiPHPerCoder 10y ago
    I added a footnote to clarify the intent. The point of short statements like that is to encourage further scrutiny from skeptical security folks. Our previous attempts just led to people nodding along and saying "Sounds great!" https://paragonie.com/blog/2016/05/keyggdrasil-continuum-cryptography-powering-cms-airship https://paragonie.com/blog/2016/05/keyggdrasil-continuum-cry...
- chrisan 10y ago
  For anyone that has used this, how are automatic updates with custom code/plugins? I think Wordpress gets a lot of flak from all of the custom code/plugins while the WP core has been pretty secure in recent years in fixing 0-days? (I'm not a WP dev, but we do contract out for our company's marketing site and just going off what I hear from them)
  - CiPHPerCoder 10y ago
    > I think Wordpress gets a lot of flak from all of the custom code/plugins while the WP core has been pretty secure in recent years in fixing 0-days? I don't entirely agree or disagree. It's a nuanced topic. The WordPress core team sat on a Unicode-based SQL injection flaw for years, after it was known to their team, then tried to sneak the fix in under the guise of Emoji support. https://kraft.im/2015/05/how-emoji-saved-your-sites-hide/ https://kraft.im/2015/05/how-emoji-saved-your-sites-hide/ Part of fixing 0-days is minimizing the feedback loop from "bug known" to "bug fixed". The other part is minimizing the feedback loop from "bug fixed" to "fix deployed". To their credit, they at least try to solve the latter problem. To their detriment, if you compromise their update server, you've got RCE on just over 25% of the websites on the Internet. (Among other things, their update hooks use unserialize(), which allows for some fun exploitation techniques.) With Airship, root access to our update server doesn't let you forge updates. You'll need an airgapped Ed25519 signing key, and then you still have a catch-22 to resolve: A. Announce your presence to the network (untargeted attack) B. Find another way to hack every other Airship just so you can perform a silent, targeted attack against a single Airship. This catch-22 makes exploiting a pilfered signing key unattractive to nation states, who generally want their activities to be covert.
    - ryanlol 10y ago
      > Among other things, their update hooks use unserialize(), which allows for some fun exploitation techniques S-s-surely not?
- anton_gogolev 10y ago
  > the time-scale that the patch will be released and applied is less than one hour, not multiple days Provided that the Auto-Updater is up and running: https://cspr.ng/blog/2016/07/cms-airship-1-1-2-stored-xss-post-mortem https://cspr.ng/blog/2016/07/cms-airship-1-1-2-stored-xss-po...
barkingcat 10y ago
Sounds a bit hyperbolic "Never again worry about zero-days."! Hooray! Install this and you'll never be hacked! I think it's good to build something with security in mind, but this just seems to be self-defeating in tone and mentality. Proceed with caution.
kijin 10y ago
Looks nice, but I don't think a CMS is the right place to do things like HPKP (HTTP public key pinning). That's the webserver's job. Any CMS can be used with HPKP if you just add a couple of lines to your Apache/nginx configuration. Many of the other items on the list are unfair to CMS's with a large and thriving plugin ecosystem. WordPress has a whole bunch of 2FA plugins to choose from. Security is a worthy goal, but when it comes to CMS's, a healthy FOSS ecosystem is just as important to support and nurture. You can't try to do everything in the core.
- CiPHPerCoder 10y ago
  > Many of the other items on the list are unfair to CMS's with a large and thriving plugin ecosystem. It is explicitly an out-of-the-box comparison. > Security is a worthy goal, but when it comes to CMS's, a healthy FOSS ecosystem is just as important to support and nurture. You can't try to do everything in the core. We agree. Airship is free software and has powerful support for plugins. We just try to solve 99% of the security problems in the core so plugin developers can just use the features we provide and don't have to worry about low-level concerns.
xenophonf 10y ago
Never again worry about zero-days. That's pure snake oil. The little asterisk compounds their mistake: Because updates are securely installed within one hour of their availability, the time-scale of a fix being applied is no longer meaningfully measured in days. Zero hours are the new zero days. That's not what "zero day" means. It isn't the time between a security fix becoming available and a vulnerable system installing said patch. Rather, it's the time between a vulnerability being discovered and said vulnerability being disclosed. It's great that this vendor has mechanism for quickly distributing security updates, but that isn't going to mitigate zero day vulnerabilities. Rather, zero days would be mitigated by SDLC activities that would help them discover novel vulnerabilities in their code, like design/code reviews, static analysis, or fuzzing. If they want to reassure their customers that they're good at infosec, then they need to do a lot more than spout some BS about how their automatic update mechanism stops zero days when it can't.
- CiPHPerCoder 10y ago
  > That's not what "zero day" means. It's half of the practical concerns with zero days, and the half that most software teams have the least amount of control over. > It's great that this vendor has mechanism for quickly distributing security updates, but that isn't going to mitigate zero day vulnerabilities. See: http://www.tripwire.com/state-of-security/incident-detection/drupal-psa-if-you-didnt-patch-within-7-hours-consider-your-site-hacked/ http://www.tripwire.com/state-of-security/incident-detection... > Rather, zero days would be mitigated by SDLC activities that would help them discover novel vulnerabilities in their code, like design/code reviews, static analysis, or fuzzing. That's correct, but nontechnical users aren't interested in these details. What's more interesting to them is "When it's fixed, I won't have to do anything to not be vulnerable." > If they want to reassure their customers that they're good at infosec, then they need to do a lot more than spout some BS about how their automatic update mechanism stops zero days when it can't. I'll refine the wording a bit better. Thanks for the feedback.
  - xenophonf 10y ago
    What's more interesting to [non-technical users] is "When it's fixed, I won't have to do anything to not be vulnerable." Then say that instead of making specious safety guarantees.
mrmondo 10y ago
The wording of this is down right irresponsible. Talk about the potential to mislead people that don't question and test the ongoing state of software. If you think you absolutely secure - you more likely to be(come) absolutely insecure. There's a reason developers of the better quality security focused software out there are the same people that are quick to point out potential flaws or weaker surfaces of their designs...
- CiPHPerCoder 10y ago
  This is a great opportunity to mention that we have a bug bounty program, as well: https://hackerone.com/paragonie https://hackerone.com/paragonie (Take note of the "average time to resolution".)
ryanlol 10y ago
If I happened to find a 0day RCE, what stops me from being mean and using the sites I compromise to DDoS the update servers?
- CiPHPerCoder 10y ago
  Nothing, to be truthful. Nothing stops you from being mean and using a pre-existing botnet to DDoS the update servers, either. Let's say you manage to pop the WordPress update server and turn every WordPress website on the Internet into a DoS bot. That's 25% of websites, and most likely a large cross-section of all available servers. There are very few networks that could possibly shoulder that traffic, and I certainly don't have the budget for it right now.
  - ryanlol 10y ago
    This is relatively easy to account for though, if updates are properly authenticated it shouldn't be much of a problem to host them in multiple locations. DDoSing s3 and competition can be excessively difficult and not every update needs to be served from there.
ryanlol 10y ago
What this page really needs is code comparisons showing why exactly CMS Airship is better than the competition. While I mostly believe the comparison chart, it just doesn't look very convincing. Shouldn't be any kind of a challenge to demonstrate than your code quality is (or at least appears to be) better than Drupals, Joomlas and WPs.
- CiPHPerCoder 10y ago
  That's a good idea. I think I'll do that on the next post.
evunveot 10y ago
On a recent (php) project, I ended up with a setup where all the source code files were owned by user A but the php-fpm pool executing them was running as user B, i.e. web requests had no way of writing or modifying a php file that could then be executed over the web. (There was a user-B-writable directory for end-user uploaded files, but none of those would ever be executed remotely due to the nginx configuration.) There was no auto-update mechanism involved, but if there were it would have been a user A cron job. Of course, you can still get yourself in trouble by doing dangerous things like mixing input with `include` or `eval`, but otherwise it seems like a strong mitigation against the worst exploits you see in php applications. Can or could Airship run in a configuration like that? It doesn't seem to be mentioned in the documentation.
- CiPHPerCoder 10y ago
  > Can or could Airship run in a configuration like that? It doesn't seem to be mentioned in the documentation. The documentation needs more TLC, and is my current focus. But yes, running the updates from a cron script under a different user than www-data (or equivalent) is not only possible, it's a good idea.

14 points by CiPHPerCoder 10y ago

Flimm 10y ago

Yes! It's about CMS's compete a bit on security. Content Security Policy needs to be by default. This page says CSP is managed "through a web interface", which worries me a bit.

CiPHPerCoder 10y ago
> This page says CSP is managed "through a web interface", which worries me a bit. Administrators can update a JSON file that is used by CSP-Builder to generate the Content-Security-Policy headers. We wanted to normalize this browser securtiy feature and make it user friendly for users to manage these headers.

CiPHPerCoder 10y ago

> Never again worry about zero-days. Before anyone asks, the point of this statement isn't "We'll never have a security hole." It's "the time-scale that the patch will be released and applied is less than one hour, not multiple days". An alternative way of putting it might be: Zero hours are the new zero days.

barkingcat 10y ago
Maybe reword that phrasing a bit then to make it mean what you want? As a server operator I will always be worried about zero days, regardless of what my cms is or who wrote the software. The person who stops worrying about it is the one who will get hacked. Maybe you mean "stop waiting for vendors to patch zero days?" And even then, once a zero-day hits, someone's going to have to write that patch, and if it's in a base library like openSSL it can be non-trivial, and you're going to have to wait regardless of what CMS you choose. Either way, the wording needs to be refined.
- CiPHPerCoder 10y ago
  I added a footnote to clarify the intent. The point of short statements like that is to encourage further scrutiny from skeptical security folks. Our previous attempts just led to people nodding along and saying "Sounds great!" https://paragonie.com/blog/2016/05/keyggdrasil-continuum-cryptography-powering-cms-airship https://paragonie.com/blog/2016/05/keyggdrasil-continuum-cry...
chrisan 10y ago
For anyone that has used this, how are automatic updates with custom code/plugins? I think Wordpress gets a lot of flak from all of the custom code/plugins while the WP core has been pretty secure in recent years in fixing 0-days? (I'm not a WP dev, but we do contract out for our company's marketing site and just going off what I hear from them)
- CiPHPerCoder 10y ago
  > I think Wordpress gets a lot of flak from all of the custom code/plugins while the WP core has been pretty secure in recent years in fixing 0-days? I don't entirely agree or disagree. It's a nuanced topic. The WordPress core team sat on a Unicode-based SQL injection flaw for years, after it was known to their team, then tried to sneak the fix in under the guise of Emoji support. https://kraft.im/2015/05/how-emoji-saved-your-sites-hide/ https://kraft.im/2015/05/how-emoji-saved-your-sites-hide/ Part of fixing 0-days is minimizing the feedback loop from "bug known" to "bug fixed". The other part is minimizing the feedback loop from "bug fixed" to "fix deployed". To their credit, they at least try to solve the latter problem. To their detriment, if you compromise their update server, you've got RCE on just over 25% of the websites on the Internet. (Among other things, their update hooks use unserialize(), which allows for some fun exploitation techniques.) With Airship, root access to our update server doesn't let you forge updates. You'll need an airgapped Ed25519 signing key, and then you still have a catch-22 to resolve: A. Announce your presence to the network (untargeted attack) B. Find another way to hack every other Airship just so you can perform a silent, targeted attack against a single Airship. This catch-22 makes exploiting a pilfered signing key unattractive to nation states, who generally want their activities to be covert.
  - ryanlol 10y ago
    > Among other things, their update hooks use unserialize(), which allows for some fun exploitation techniques S-s-surely not?
anton_gogolev 10y ago
> the time-scale that the patch will be released and applied is less than one hour, not multiple days Provided that the Auto-Updater is up and running: https://cspr.ng/blog/2016/07/cms-airship-1-1-2-stored-xss-post-mortem https://cspr.ng/blog/2016/07/cms-airship-1-1-2-stored-xss-po...

barkingcat 10y ago

Sounds a bit hyperbolic "Never again worry about zero-days."! Hooray! Install this and you'll never be hacked! I think it's good to build something with security in mind, but this just seems to be self-defeating in tone and mentality. Proceed with caution.

kijin 10y ago

Looks nice, but I don't think a CMS is the right place to do things like HPKP (HTTP public key pinning). That's the webserver's job. Any CMS can be used with HPKP if you just add a couple of lines to your Apache/nginx configuration. Many of the other items on the list are unfair to CMS's with a large and thriving plugin ecosystem. WordPress has a whole bunch of 2FA plugins to choose from. Security is a worthy goal, but when it comes to CMS's, a healthy FOSS ecosystem is just as important to support and nurture. You can't try to do everything in the core.

CiPHPerCoder 10y ago
> Many of the other items on the list are unfair to CMS's with a large and thriving plugin ecosystem. It is explicitly an out-of-the-box comparison. > Security is a worthy goal, but when it comes to CMS's, a healthy FOSS ecosystem is just as important to support and nurture. You can't try to do everything in the core. We agree. Airship is free software and has powerful support for plugins. We just try to solve 99% of the security problems in the core so plugin developers can just use the features we provide and don't have to worry about low-level concerns.

xenophonf 10y ago

Never again worry about zero-days. That's pure snake oil. The little asterisk compounds their mistake: Because updates are securely installed within one hour of their availability, the time-scale of a fix being applied is no longer meaningfully measured in days. Zero hours are the new zero days. That's not what "zero day" means. It isn't the time between a security fix becoming available and a vulnerable system installing said patch. Rather, it's the time between a vulnerability being discovered and said vulnerability being disclosed. It's great that this vendor has mechanism for quickly distributing security updates, but that isn't going to mitigate zero day vulnerabilities. Rather, zero days would be mitigated by SDLC activities that would help them discover novel vulnerabilities in their code, like design/code reviews, static analysis, or fuzzing. If they want to reassure their customers that they're good at infosec, then they need to do a lot more than spout some BS about how their automatic update mechanism stops zero days when it can't.

CiPHPerCoder 10y ago
> That's not what "zero day" means. It's half of the practical concerns with zero days, and the half that most software teams have the least amount of control over. > It's great that this vendor has mechanism for quickly distributing security updates, but that isn't going to mitigate zero day vulnerabilities. See: http://www.tripwire.com/state-of-security/incident-detection/drupal-psa-if-you-didnt-patch-within-7-hours-consider-your-site-hacked/ http://www.tripwire.com/state-of-security/incident-detection... > Rather, zero days would be mitigated by SDLC activities that would help them discover novel vulnerabilities in their code, like design/code reviews, static analysis, or fuzzing. That's correct, but nontechnical users aren't interested in these details. What's more interesting to them is "When it's fixed, I won't have to do anything to not be vulnerable." > If they want to reassure their customers that they're good at infosec, then they need to do a lot more than spout some BS about how their automatic update mechanism stops zero days when it can't. I'll refine the wording a bit better. Thanks for the feedback.
- xenophonf 10y ago
  What's more interesting to [non-technical users] is "When it's fixed, I won't have to do anything to not be vulnerable." Then say that instead of making specious safety guarantees.

mrmondo 10y ago

The wording of this is down right irresponsible. Talk about the potential to mislead people that don't question and test the ongoing state of software. If you think you absolutely secure - you more likely to be(come) absolutely insecure. There's a reason developers of the better quality security focused software out there are the same people that are quick to point out potential flaws or weaker surfaces of their designs...

CiPHPerCoder 10y ago
This is a great opportunity to mention that we have a bug bounty program, as well: https://hackerone.com/paragonie https://hackerone.com/paragonie (Take note of the "average time to resolution".)

ryanlol 10y ago

If I happened to find a 0day RCE, what stops me from being mean and using the sites I compromise to DDoS the update servers?

CiPHPerCoder 10y ago
Nothing, to be truthful. Nothing stops you from being mean and using a pre-existing botnet to DDoS the update servers, either. Let's say you manage to pop the WordPress update server and turn every WordPress website on the Internet into a DoS bot. That's 25% of websites, and most likely a large cross-section of all available servers. There are very few networks that could possibly shoulder that traffic, and I certainly don't have the budget for it right now.
- ryanlol 10y ago
  This is relatively easy to account for though, if updates are properly authenticated it shouldn't be much of a problem to host them in multiple locations. DDoSing s3 and competition can be excessively difficult and not every update needs to be served from there.

ryanlol 10y ago

What this page really needs is code comparisons showing why exactly CMS Airship is better than the competition. While I mostly believe the comparison chart, it just doesn't look very convincing. Shouldn't be any kind of a challenge to demonstrate than your code quality is (or at least appears to be) better than Drupals, Joomlas and WPs.

CiPHPerCoder 10y ago
That's a good idea. I think I'll do that on the next post.

evunveot 10y ago

On a recent (php) project, I ended up with a setup where all the source code files were owned by user A but the php-fpm pool executing them was running as user B, i.e. web requests had no way of writing or modifying a php file that could then be executed over the web. (There was a user-B-writable directory for end-user uploaded files, but none of those would ever be executed remotely due to the nginx configuration.) There was no auto-update mechanism involved, but if there were it would have been a user A cron job. Of course, you can still get yourself in trouble by doing dangerous things like mixing input with `include` or `eval`, but otherwise it seems like a strong mitigation against the worst exploits you see in php applications. Can or could Airship run in a configuration like that? It doesn't seem to be mentioned in the documentation.

CiPHPerCoder 10y ago
> Can or could Airship run in a configuration like that? It doesn't seem to be mentioned in the documentation. The documentation needs more TLC, and is my current focus. But yes, running the updates from a cron script under a different user than www-data (or equivalent) is not only possible, it's a good idea.