paragonie / airship Goto Github PK

• PSR-9
  • Security Advisories
• PSR-10
  • Vulnerability Disclosure

Preliminary Requirements:

• Needs to work in a Tor-friendly environment, no metadata or real identity attachments like Google Auth
• Needs to work for people without special hardware
• Needs to be easy-to-use; not GPG-encrypted emails.

The end goal might end up being multiple 2FA options, with the Airship captain choosing which ones they want to support.

See the discussion in #55

The installer has a hardcoded version of 0.2.0, should be 1.0.2.

Right now, I've only written support for PostgreSQL. Before v1.0.0, we should also support MySQL backends.

Figured this is worth tracking since it's probably a critical component for any production usage.

I mentioned this elsewhere, but:

We're going to release v1.1.0 tomorrow then proceed with the original plan for v1.1 as v1.2.0 in October. At that point, the master branch will be intended for v2 (PHP 7.1+).

This change was motivated by several UI/UX enhancements that don't make sense to include in a 'patch' release.

Although HPKP can be a self-DoS foot-gun if you have to revoke a key (since your users will reject any unpinned keys), we should allow people to specify HPKP headers in the cabin configuration.

Draft Requirements:

• Require at least two sha256 fingerprints. One for the current certificate, and at least one backup public key.
• Clearly document the use-case of this feature and how to generate the sha256 fingerprints.

src/Installer/default_pages contains the Markdown definitions for the default values for the two custom pages we defined at install time: The about page and the contact page.

Is there anything we can do to improve their default values?

Summary

Installer loads without CSS from the /static/Hull public directory.

Expected Outcome

Installer loads with styles.

What Actually Happened

These two guys 404 so we are left with a largely unstyled installer.

<link rel='stylesheet' href='/static/Hull/base.css' />
<link rel='stylesheet' href='/static/Hull/motif/airship-classic/style.css' />

My /src/public/static directory is empty.

The final beta looks like this:

• #22 - Password Reset Feature
• #25 - Gearify the Cabin Classes
• #23 - Make Comments Compatible with Static Pages
• #24 - Web Interface for Managing Packages
• #30 - Two-Factor Authentication
• #35 - Progressive Login Attempt Rate-Limiting
• #34 - Optional HPKP Headers

Afterwards, I'll spend a bunch of time on boyscouting.

Between now and v1.0.0, I need to identify (or alternatively, create) a secure WYSIWYG editor for blog posts, etc. Not everyone is fluent with HTML, ReStructuredText, or Markdown.

The README is boring. We should make it showcase how awesome this project is and how much more fundamentally secure it is than the alternatives.

Summary

Links to and within the bridge are invalid because the canon URL is not being used or set properly. Reproduced by creating a new airship instance, running the installer and setting a bridge canon URL of whatever.com/bridge

Expected Outcome

Everything links together. The link to the bridge on the bottom of the Hull should go to /bridge/ on my install.

What Actually Happened

The Bridge link at the bottom of the Hull just goes to "/". Links within the Bridge (by manually going to /bridge) are invalid as they are missing the bridge prefix. When I go to airship.app/bridge/cabins/manage/Bridge to see what my canon URL is actually set to it was set to "//" despite what I entered in the installer.

Upon correcting that form to the URL I actually want nothing happens to the links. It gives me an additional (unrelated?) PHP error:

Warning: file_put_contents(/var/www/src/config/Bridge/content_security_policy.json): failed to open stream: No such file or directory in /var/www/src/Cabin/Bridge/Landing/Cabins.php on line 185

Between now and version 1.0.0, we should make a list of things Airship does better than the existing CMSes, and how these benefits relate to (quoting a Reddit post with feedback from bopp):

• Developers: These are the backend-developers. The people who install the CMS, configure it, and build any custom functionality.
• Implementors: These are the "frontend developers". The people who structure the content, set up the contenttypes, and implement the theming of the website in HTML/CSS in the templating language provided by the CMS.
• Editors: These are the people who work in the CMS on a daily basis. They write new content, edit existing pages, etc.

I'd also like to add to this list for a few more use-cases:

• Pseudonymous publishers: Activists or entertainers who wish to publish their content on a Tor Hidden Service for their safety and/or to protect the enigma of their persona. We should go out of our way to protect the server's IP and use authors rather than users for any public interaction.

It should be possible for a novice to set Airship up. Note that part of this might not be possible until PHP 7.1 (assuming they decide to make libsodium a core class, which isn't a given).

Summary

Using current master branch

I go to https://url.tld/bridge/admin/settings, check "Notarize Updates for other Airships?", and click "Save Settings".
Next, I log out of Bridge, and I restart php fpm on my server.
I then go to https://url.tld to find nginx gives me a 500 error.

Further investigation suggests that when I saved the settings, config/universal.json was updated and saved null for notary/channel. Digging through the nginx error logs I find a fatal error, caused by \Airship\Engine\Security\Util::noHTML having its first parameter typed to string, but receiving null instead.

Manually updating universal.json to set the channel back to paragonie, and restarting php fpm fixes this.

Expected Outcome

universal.json is updated correctly, and navigating to Hull should not trigger a fatal error

What Actually Happened

universal.json is updated, but notary config is "incomplete"

{
    /* Universal Configuration for an Airship deployment */
    "airship": {
        "trusted-supplier": "paragonie"
    },
    "auto-update": {
        "ignore-peer-verification": false,
        "check": 3600,
        "major": false,
        "minor": true,
        "patch": true,
        "test":  false
    },
    "cookie_index": {
        "auth_token": "airship_token"
    },
    "debug": false,
    "email": {
        "from": null
    },
    "guest_groups": [
        1
    ],
    "ledger": {
        "driver": "file",
        "path":   "\/tmp\/airship.log"
    },
    "guzzle": [],
    "notary": {
        "channel": null,
        "enabled": true
    },
    "session_config": {
    "cookie_domain": ""
},
    "session_index": {
        "user_id": "userid",
        "logout_token": "logout_token"
    },
    "tor-only": false,
    "twig-cache":  true
}

Stack trace from nginx error log

PHP message: PHP Fatal error:  Uncaught TypeError: Argument 1 passed to Airship\Engine\Security\Util::noHTML() must be of the type string, null given, called in /{path}/src/lens_functions.php on line 317 and defined in /{path}/src/Engine/Security/Util.php:34
Stack trace:
#0 /{path}/src/lens_functions.php(317): Airship\Engine\Security\Util::noHTML(NULL)
#1 /{path}/vendor/twig/twig/lib/Twig/Environment.php(403) : eval()'d code(65): Airship\LensFunctions\display_notary_tag()
#2 /{path}/vendor/twig/twig/lib/Twig/Template.php(167): __TwigTemplate_35bb9ec878691b75b1629a21ef6449901f542f500bcc9d2f8ce3c2c7ffb6927a->block_head(Array, Array)
#3 /{path}/vendor/twig/twig/lib/Twig/Environment.php(403) : eval()'d code(32): Twig_Template->displayBlock('head', Array, Array)
#4 /{path}/vendor/twig/twig/lib/Twig/Template.php(387): __TwigTemplate_35bb9ec878691b75b1629a21ef6449901f542f500bcc9d2f8ce3c2c7ffb6927a->doDisplay(Array, Array)

Common Issues

Please make sure all these boxes are checked before you submit your issue.

• You are running a supported version of PHP (7.0.x) (Run php -v from the command line)
• You have libsodium 1.0.9 or newer installed
• You have version 1.0.3 or newer of the PHP extension for libsodium installed

Summary

Absolute symlinks are preventing Airship from working correctly when it's not placed in /var/www/airship

Expected Outcome

CSS and other public resources load.

What Actually Happened

They effectively 404 due to broken symlinks.

Links as of 72968a9:

Klingon:airship kmark$ find . -type l -ls
25630353        8 lrwxr-xr-x    1 kmark            staff                  53 Apr  6 14:20 ./src/Cabin/Bridge/Lens/motif/airship-classic -> /var/www/airship/src/Motifs/paragonie/airship-classic
25630406        8 lrwxr-xr-x    1 kmark            staff                  60 Apr  6 14:20 ./src/Cabin/Bridge/public/motif/airship-classic -> /var/www/airship/src/Motifs/paragonie/airship-classic/public
25630479        8 lrwxr-xr-x    1 kmark            staff                  53 Apr  6 14:20 ./src/Cabin/Hull/Lens/motif/airship-classic -> /var/www/airship/src/Motifs/paragonie/airship-classic
25630480        8 lrwxr-xr-x    1 kmark            staff                  53 Apr  6 14:20 ./src/Cabin/Hull/Lens/motif/airship-supreme -> /var/www/airship/src/Motifs/paragonie/airship-classic
25630489        8 lrwxr-xr-x    1 kmark            staff                  60 Apr  6 14:20 ./src/Cabin/Hull/public/motif/airship-classic -> /var/www/airship/src/Motifs/paragonie/airship-classic/public
25630490        8 lrwxr-xr-x    1 kmark            staff                  60 Apr  6 14:20 ./src/Cabin/Hull/public/motif/airship-supreme -> /var/www/airship/src/Motifs/paragonie/airship-classic/public

There should be a Dockerfile to make deployment easy. This especially makes it easier to set it up to have just a quick look at it.

We actually recommend Caddy over Apache or nginx due to its seamless LetsEncrypt integration (automatic HTTPS). Some time in the future, I'd like to play around with Docker and create a Dockerfile that installs and sets up Caddy.

If anyone wants to give this a swing before 2.0.0 is ready, I'd greatly appreciate it. Otherwise, I will eventually find time to tackle this.

I forgot to implement directory redirect creation.

The original signing keys were generated before Argon2i support was merged. I should generate a new keypair and update the corresponding public keys.

• Check this box if this is a security vulnerability.

Summary

If you fail to use the correct username&password for your database you just get a blank screen at the end of the install process due to a 500 server error

Expected Outcome

Failure in UI shown, potentially bounce back to the database configuration screen

What Actually Happened

Blank screen shown due to 500 server error
Password shown in error.log logs, unsure if this is considered privileged?

[Tue Jun 28 01:43:52.244561 2016] [:error] [pid 15927] [client 192.168.2.146:39360] PHP Notice:  Undefined index: databases in /var/www/html/airship/src/Installer/Install.php on line 414, referer: http://appserv-ub03/
[Tue Jun 28 01:43:52.264859 2016] [:error] [pid 15927] [client 192.168.2.146:39360] PHP Fatal error:  Uncaught Airship\\Alerts\\Database\\DBException: Could not create a database connection. Please check your username and password. in /var/www/html/airship/src/Engine/Database.php:95\nStack trace:\n#0 /var/www/html/airship/src/Installer/Install.php(534): Airship\\Engine\\Database::factory('pgsql:host=loca...', 'postgres', 'secret...', Array)\n#1 /var/www/html/airship/src/Installer/Install.php(478): Airship\\Installer\\Install->finalDatabasePrimary()\n#2 /var/www/html/airship/src/Installer/Install.php(294): Airship\\Installer\\Install->finalDatabaseSetup()\n#3 /var/www/html/airship/src/Installer/Install.php(132): Airship\\Installer\\Install->finalize(Array)\n#4 /var/www/html/airship/src/Installer/launch.php(171): Airship\\Installer\\Install->currentStep()\n#5 /var/www/html/airship/src/public/index.php(26): include('/var/www/html/a...')\n#6 {main}\n  thrown in /var/www/html/airship/src/Engine/Database.php on line 95, referer: http://appserv-ub03/

Setting up the root user named test with password test results in an internal error (500) and a blank page.

Maybe based on Elastic Search. If Docker is the main mode of installation, it's easy to add it in a separate container and doesn't make setup any harder.

In addition to the work we're doing with Keyggdrasil (explanation, Github issue), we could also maintain a separate tree of the checksums of all extension updates.

Roughly the same implementation details will apply. We just need:

• Supplier
• Extension name
• Extension type
• Version
• Date
• BLAKE2b-512 checksum of the update
  • Note: We will NOT be storing the update itself in the tree.

Since the update itself is signed by the developer using barge, we might be able to omit a dev-signature on this metadata. It's only meant to keep the Channel from doing a silent and targeted substitution should it obtain one of the supplier's signing keys.

• Check this box if this is a security vulnerability.

Summary

Certain metatags are used for embedding summaries in certain social media sites and improving the experience (an potentially rankings) on search aggregators.

A few searches brought up these examples:
http://ogp.me/
The Open Graph protocol is an open standard for these types of things and a minimal subset would likely be trivial to enable given the fields of content types.

Airship should consider targeting Facebook, Twitter, G+ with any specific metatags that focus on them, as well as more general ones like in ogp.me (which I believe satisfies Facebook)

Just to document what I'm currently working on, which is a blocker for some of the other high priority issues:

I'm building a system that allows developers using barge to upload their public keys, which will then be synchronized out to the entire network.

Threat Model

We want to protect against these threats:

• An attacker capable of compromising the package server (ours is called the Skyport) who wants to replace the public key for a specific supplier, silently, and only for specific clients. (If this succeeds, it allows them to produce forged automatic updates for that supplier.)
• A nation-state attacker armed with the capability to perform legal coercion attacks against our infrastructure, who might want to perform silent targeted attacks.

This does not try to protect against:

• Signing key theft.
• Malicious package developers.

The goal is to place less automatic trust in the infrastructure that updates are delivered through, and instead encourage informed trust decisions for the developers of the updates themselves.

Solution

We will maintain a Merkle tree of all key transactions (insert/delete) from the day version 1.0.0 is released. Every Airship that communicates with our Skyport will maintain a mirror of this data structure.

Every Airship operator will be able to add their own notaries whom they trust to vouch for the authenticity of this Merkle tree.

Upon a new key being created, or an old key being revoked, each Airship will:

1. Download the new key information and the Merkle root for each update.
2. Select a random notary from their individually trusted peers. (The package server MUST have no record of who trusts which notaries.)
3. Send this chosen notary a challenge nonce and sequence number for the latest node (which the notary will sign along with the corresponding Merkle root).
4. Verify the Ed25519 signature of the notary's response and check that the nonce is the same one that was sent.
5. Repeat steps 2-4 for several notaries (if more than one is configured).

If the Merkle root doesn't match the one your notaries send for that sequence number (or all of your notaries have no knowledge of this sequence number even after they poll the server), it will discard one backtrack and start over until it finds a match. If none are found, all updates are discarded.

To identify attacks, all mismatched roots can optionally be broadcasted to our security team. ("Scream bloody murder.")

Keyggdrasil

Name: Key + Yggdrasil, which in Norse mythology is the World Tree.

This is an (currently not finished) implementation of the above solution. We are taking inspiration from Convergence and Certificate Transparency to provide a decentralized verification mechanism.

• Cabins
  • Can be disabled
  • Can be uninstalled
• Gadgets
  • Can be disabled
  • Can be rearranged
  • Can be uninstalled
• Motifs
  • Can be disabled
  • Can be uninstalled
• Bridge - Captain Announcements
  • Can be dismissed
• Opt-in User Directory (Display Name + Public ID)
• Help/Support page

First, I need to make sure version 0.2.0 is out.

Afterwards, I'm going to be switching gears to work on several RFCs for PHP 7.1. It might take a couple of days for me to pick Airship back up. During that time, please try to break things. You should be able to use barge to create and deploy gadgets, cabins, and motifs through our server.

(If all goes well, PHP 7.1 will come with libsodium which will make Airship 2.0.0 much easier for non-root users to install.)

Version 0.3.0 will contain bug fixes for whatever I missed and focus on UI/UX. Namely: being able to install/uninstall gadgets, motifs, and cabins from within Airship itself. If all goes well, you should be automatically updated to version 0.3.0 from Continuum.

Version 0.4.0 will be a pre-1.0.0 refactor, where I clean up anything that became messy and ensure we're using strict type declarations (and return types) everywhere possible.

If there is a version 0.5.0 or 0.6.0 (etc.), it will be because we need to test more things. I don't have any plans at the moment that necessitate these version numbers be used, however.

EDIT: There will only be 3 beta releases, barring any catastrophes.

Version 1.0.0 will mark the first stable release of Airship, which means I'll be nuking the Skyport database and starting over from 0. This should be a rapid development effort; if my estimate is right, we'll see 1.0.0 before the end of June.

• Users can opt-out. This is the most important requirement.
• Email a one-time authentication token.
• Possible: Optional GPG public key + encryption.

• Check this box if this is a security vulnerability.

Expected Outcome

I want to be able to completely remove my account from a site. Right to be forgotten, and whatnot.

What Actually Happened

I went to my profile, but couldn't find an option to delete my account.

Between v0.2.0 and v0.3.0, we closed #33 by adding an input filtration system.

• InputFilterContainer is an invokable class that applies rigorous type-safety to a multidimensional array.
• InputFilter is a specific filter rule.

As per 75961d9 we should apply it to every instance of user input. This adds a degree of type safety to previously unstructured data, and will prevent minor nuisances (e.g. E_NOTICE leaking full path information).

• Figure out where/how to store data about "which versions of which packages are available", so we don't just fire off requests that involve large SELECT queries every time someone loads the page. Keyggdrasil is a good candidate for this.
• Design the user interface, with all of its bells and whistles.
• Create a process/workflow for installing or manually upgrading packages.
• Manual upgrades

...possibly, as an additional format option.

The order of priorities for developing version 1.x was as follows:

1. Security
2. Usability ("Security at the expense of usability comes at the expense of security." - Avi Douglen)
3. Visual appeal.

With the first two squared away, we should focus on making Airship aesthetically pleasing by default.

You can see a live deployment of the master branch at http://cspr.ng

https://github.com/paragonie/airship/blob/master/src/Engine/Security/CSRF.php#L123 will raise a notice if there's no : (colon) in the provided token. It's rejected, but clean code shouldn't throw any notices.

We need to be able to say, "Yes, this build was reproduced identically from the source code."

The only way I can think to do this reliably is to spin up a cluster of servers running Pharaoh (and equivalent) to diff the Phars for each package.

When a developer uploads a file with barge, they must include a git commit ID, which will be used in conjunction with their repository URL to ask Pharaoh to reproduce it.

My "it's 1:40 AM and I need sleep but want to get this on paper" thoughts on this:

• Should we run the checks locally? (By installing Pharaoh.)
  • This should probably at least be an optional failsafe.
• This requires that the project be open source for the "reproducible": true flag to get set by the channel when the user retrieves updates.
• What do we do if the project is closed source?
  • Mark it as unreproducible when the user is selecting gadgets, motifs, etc.?
  • Fail open -- it's not open source anyway so we can't guarantee the security here.
• What do we do if the project is open source but the reproducibility verification fails?
  • Let the user AND the supplier set their policy; most restrictive wins?
    • Require reproducibility? Y/N

If @defuse has any comments, I'd love to hear them.

Per @co60ca in this tweet, I should look into supporting LaTeX->HTML parsers and add it to the format list.

As always, our priorities are:

1. Security
2. Usability
3. Ease-of-integration (kludgy code is hard-to-audit code)

• Check this box if this is a security vulnerability.

Summary

From the docker image in #55 if you use:

host: localhost
user: airship
password: secret
database: airship

for the Database setup screen then use seemingly any username/password combination for the step in question you will get a 500 error and the following message in error.log in apache.

[Thu Jun 30 22:00:53.693308 2016] [:error] [pid 20] [client 192.168.2.146:35356] PHP Fatal error:  Uncaught Error: Undefined constant 'Sodium\\CRYPTO_PWHASH_OPSLIMIT_INTERACTIVE' in /var/www/airship/vendor/paragonie/halite/src/KeyFactory.php:344\nStack trace:\n#0 /var/www/airship/vendor/paragonie/halite/src/Password.php(30): ParagonIE\\Halite\\KeyFactory::getSecurityLevels('interactive')\n#1 /var/www/airship/src/Installer/Install.php(235): ParagonIE\\Halite\\Password::hash('areallyfuckingl...', Object(ParagonIE\\Halite\\Symmetric\\EncryptionKey))\n#2 /var/www/airship/src/Installer/Install.php(115): Airship\\Installer\\Install->processAdminAccount(Array)\n#3 /var/www/airship/src/Installer/launch.php(171): Airship\\Installer\\Install->currentStep()\n#4 /var/www/airship/src/public/index.php(26): include('/var/www/airshi...')\n#5 {main}\n  thrown in /var/www/airship/vendor/paragonie/halite/src/KeyFactory.php on line 344, referer: http://appserv-ub03:8080/

Expected Outcome

Move onto the next setup screen

What Actually Happened

500 server error.

Also it appears the password is leaked here again 'areallyfuckingl...'

Not right now, but hopefully sooner than later, we will be tagging v1.0.0.

After that has come to pass, and Airship is 100% stable and ready to be deployed in development environments, I will be investing significant time into making sure there is plenty of educational material available via tutorials and podcasts.

Are you interested in furthering this effort? Please do, and let me know so I can curate this material and ensure you're given due credit.

Continuum needs to be able to automatically update:

• Airship itself
• Cabins
• Gadgets
• Motifs

Airship

Deliverable: PHP Archive and signature

Airship updates are made with the bundled hangar tool. (This is bundled with Airship instead of separately.)

Cabins

Deliverable: PHP Archive and signature

People may choose to develop their own Cabins and publish update files through our Skyport (or their own). Even if nobody else does, Paragon Initiative Enterprises certainly will be doing this.

Cabins should be easily started and managed by barge.

Gadgets

Deliverable: PHP Archive and signature

Gadgets are used to extend the functionality of Airship and/or specific cabins. They're analogous to what other CMSes call "plugins".

Gadgets should be easily started and managed by barge.

Motifs

Deliverable: ZIP Archive/Tarball and signature

Motifs just need to be verify then extract. Using barge.

Summary

As on Twitter it may be pertinent to explain that the commercial license is available to companies that require commercial licenses and does not preclude uses in other projects that: are free to use, free to distribute, or free to sell as per the language of the GPL.

• Check this box if this is a security vulnerability.

Summary

If you are using localhost as a database host it will give

Could not create a database connection. Please check your username and password.

if you do not replace the placeholder value of localhost with the word localhost or any loopback.

This is more of a UX issue than a bug IMHO but I think most would assume if the placeholder is there you don't have to fill it in. I suppose your use of "(optional)" on Port should indicate that all other fields are required, but this isn't super user friendly.

Expected Outcome

It should use localhost anyway, perhaps set the value of database_0_host's input to localhost instead of the placeholder, or set a default on the backend to try localhost if the field isn't set.

What Actually Happened

Returns to credential screen

Relevant Debug Information

These must be completed in this specific order:

• #13
• #6
• #11
• #12

Then I have a lot of tedious UI stuff (and CRUD) to complete before v0.2.0 is tagged.

Disregard. I was testing.

When many failed login attempts come from the same IP or user account, we should pause for a progressively longer time before beginning the Argon2i verification, growing exponentially until the delay reaches a cap. For example:

• 1 failed attempt -> 0.25s
• 2 failed attempts -> 0.5s
• 3 failed attempts -> 1.0s
• 4 failed attempts -> 2.0s
• 5 failed attempts -> 4.0s
• 6 failed attempts -> 8.0s
• 7 failed attempts -> 16.0s
• 8+ failed attempts -> 30.0s (assuming a cap of 30 seconds)

Additionally, after N (default: 3) failed attempts, we could allow the admin to optionally seal-then-log the attempted usernames and passwords.

This will help against two possible attacks:

1. Online password guessing (which should be futile with strong passwords).
2. Attempting to DoS via CPU usage in the Argon2i calculation.

Thanks to @jedisct1 for reminding me of these attack vectors.