blackbox icon indicating copy to clipboard operation
blackbox copied to clipboard

Blackbox security/integrity can be undermined in several ways

Open Lightning- opened this issue 1 year ago • 3 comments

This is gonna be a long one with some complexity, please feel free to get in touch with me for further clarification if needed :).

Summarizing the core problem: Blackbox does not ensure validity/plausibility of the delivered keyring and "admin files"; as well "collisions" (let's call it that way for now) with the personal keyring are not prevented.

It starts with blackbox-admins.txt which can simply be edited by everyone with repository write access, even if that person is not meant to administer Blackbox secrets at all; here an issue ticket already exists → https://github.com/StackExchange/blackbox/issues/9
Basically there's no big need to explain how to exploit this: think about a repository for a wiki where people do have read and write access to the content but not everybody should be able to read also-stored password files. Create a big "fix syntax/formatting" commit, hide changes to blackbox-admins.txt in there and be patient till things get re-encrypted (exploit chain follows).
Beside that, blackbox-files.txt can be edited in a similar way, this just doesn't harm anyone as there potentially will be files encrypted that shouldn't.

Almost similar to those: delivered pubring (which simply gets imported to the personal pubring in _blackbox_common.sh) can be "enriched" by additional keys (or even subkeys, to make it less obvious) the same way.
Beyond combining manipulation of blackbox-admins.txt and the pubring with fresh entries, you also can inject a forged (sub)key for an existing entry of blackbox-admins.txt and replace the current one in the keyring. As well, dependent on sort order of GPG keys/subkeys, you might get things encrypted for you even if there are 2 different keys for the same list entry.

Next: Blackbox doesn't care about whether the used keys are actually the ones that should be used according to the delivered keyring. After importing delivered keys into the personal keyring, the key selection is left to GPG based on the eMail address (or whatever selection criteria is used in blackbox-admins.txt; which doesn't need to be unique/pseudo-unique). So if I have 2 keys for the same address in my personal keyring, this might lead to kicking out somebody from encryption unintentionally (in best case). Worst case (think of previous forgery ideas) is, that I encrypt secrets to people that simply shouldn't get them.

Last, but not least important: Blackbox explicitly/intentionally bypasses the web of trust (see here). This means that even in a fully trusted environment, where people do proper keysigning, building up clean trustdbs, maybe do have a company signing key that signs keys for employees and hands them over on smartcard/Yubikey etc. Blackbox kills the strongest safety net that PGP/GPG has. While the web of trust would have caught some of the potential security issues or problems before, this possibility is eliminated here.

Combining these problems there are several ways to play around, trick around, obfuscate evil things, ... and get secrets that you shouldn't have!
Some problems additionally lead to unexpected behavior ("this is encrypted for the wrong key").

Asking questions and suggesting solutions

Checksum + Signature

Checksum and cryptographically sign the checksums the same way that is common for any random open source project.
So place a checksums-file in keyrings/live or .blackbox directory that holds the current checksums for blackbox-admins.txt, blackbox-files.txt and pubring.gpg and make the editor cryptographically sign that checksums-file whenever changes are done here. This speaks as "I am a legit BB admin, made changes to those files, sign this with my key and everyone can verify this".
Before encrypting any data, verify the checksums, the signature and the trustworthiness of the signing key and bail out if something is wrong here!
This is barely more than sha256sum blackbox-admins.txt blackbox-files.txt pubring.gpg > checksums.sha256, gpg2 --local-user identifier_of_used_blackbox_key --detach-sig -a checksums.sha256, gpg2 --verify checksums.sha256.asc and sha256sum -c checksums.sha256.

Why importing the delivered keyring and not using it directly?

As BB already delivers a maintained keyring (which is checksummed and signed ;)) containing all used pubkeys, why importing this into the personal keyring and not use it directly by --keyring along with --no-default-keyring? It might be beneficial for people to use their personal pubrings anyways, but making this an option (ENV-VAR, cli parameter, config file, ...) and not the default would feel way more intuitive and kill many wanted/unwanted misbehaviors.

Identify keys by ID or fingerprint not by eMail

Of course, randomly looking numbers don't please a user, but maintaining a file that maps the configured addresses to IDs/fingerprints and just use those IDs/fingerprints in the gpg command lines would kill many collisions or mis-picks of keys. Receive valid IDs/fingerprints from pubring (checksummed, signed, ...), dump them to a file, checksum it, sign it and you're pretty safe.

Fingers off the web of trust

If a user wants to bypass the web of trust in some way, he's free to set his favorite trust model in his gpg.conf, but bypassing the trust model hardcoded is imho a no-go. Don't kill essential security features of PGP/GPG that would have saved you from (security) issues!

Lightning- avatar Oct 31 '23 16:10 Lightning-