d047891ded18c5ebf84d5e6d01c9b7c497c373e9
3
Commits
| Author | SHA1 | Message | Date | |
|---|---|---|---|---|
 Bernd RodlerandClaude Opus 4.8
|
d047891ded |
test(smime): real crypto round trip against the patched plugin
Adds roundtrip.mjs, which drives the plugin's own modules directly — no browser, no DOM — and proves the three audit fixes did not break S/MIME. 24 assertions, all passing, against the self-signed spike certificates: PKCS#12 import (both identities, RSA-2048, kdf=600000) key encrypted at rest (32-byte salt, 12-byte IV) unlock yields NON-EXTRACTABLE keys; wrong passphrase rejected sign -> verify: signature valid, signer email matches From encrypt -> decrypt by the intended recipient, plaintext matches sender can read their own Sent copy downgraded message produces no plaintext Two results worth recording. Finding 1 is confirmed against a genuine CMS structure, not just a mock: the spike certs are self-signed, smimeVerify reports signatureValid AND signerEmailMatch true AND selfSigned true, and the gate refuses the auto-import. That is exactly the cert-substitution attack, blocked. The same status with selfSigned:false passes, so the gate is not simply refusing everything. Finding 2 is confirmed end to end: our own encrypt path produces AES-256-GCM, decrypt reports contentAuthenticated:true, so HTML renders without suppression. Only legacy inbound CBC degrades to text. The section-8 assertion is deliberately loose. Swapping the 9-byte AES-GCM OID for the 8-byte 3DES OID also invalidates the enclosing DER lengths, so ASN.1 validation rejects the message before the allowlist is reached — either way no plaintext is produced, and the assertion says which path fired rather than pretending it tested the allowlist. The allowlist itself is asserted precisely in verify-fixes.mjs, which now carries 36 assertions including checks that fail if a legacy CBC OID reappears or the mail path stops using the native engine. Browser-side spike result: the patched plugin installs through the admin channel, resolves to the privileged tier, and activates with "hooks=5, slots=3" and no refusals — so the B-04 gate does not block it. Its S/MIME settings section renders and survives SPA navigation. Key import via the UI could not be automated (native file picker), which is a harness limit rather than a product defect; roundtrip.mjs covers that path directly instead. Findings 4, 5 and 6 remain open. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com> |
||
|
Bernd RodlerandClaude Opus 4.8
|
bc5d2a57e8 |
security(smime): fix audit finding 2 — unauthenticated CBC on decrypt
Upstream applied no content-encryption check at all on decrypt, and ran every decryption through the liner engine — which registers DES-CBC, 3DES-CBC and RC2-CBC. Those OIDs exist in crypto-engine.js for PKCS#12 password-based encryption; the CMS content path merely reused the same engine and inherited them. A crafted message could therefore be decrypted under a broken cipher, and unauthenticated plaintext was handed straight to the renderer — the EFAIL precondition. The obvious fix would have been wrong. Accepting only AEAD breaks most real S/MIME mail: RFC 5751 makes AES-128-CBC the MUST-implement content cipher, Outlook and Thunderbird default to CBC, and AES-GCM in CMS (RFC 5084) is barely deployed. An AEAD-only allowlist is a functionality catastrophe wearing a security fix's clothes. Three layers instead: 1. Allowlist the AES family and refuse everything else, with the gate running before any private key is touched. CBC stays for interop; DES/3DES/RC2 are refused. 2. Take the mail path off the legacy engine. Normal decryption now uses nativeEngine(); the liner engine is reachable only when a genuine legacy RSAES-PKCS1-v1_5 key is in play. This removes the weak ciphers structurally rather than by policy — native WebCrypto handles RSA-OAEP key transport and AES-CBC/GCM content perfectly well. 3. Refuse to render unauthenticated plaintext as HTML. CBC output is malleable and HTML is EFAIL's exfiltration channel. The host does block remote content by default (allowExternalContent starts false), but that is a user/admin setting this plugin cannot observe, so we don't lean on it. New renderUnauthenticatedHtml setting (default false) is the documented opt-out. Our own encrypt path always uses AES-GCM, so mail we send renders fully; only legacy inbound CBC degrades to text. Built from source with the repo's own pipeline (esbuild, 1.69 MB) and packaged to smime-vnc.zip (0.27 MB). All four fixes verified present in the built bundle. Build output is gitignored — never vendor a prebuilt bundle, which was the upstream mistake. Correcting an earlier assumption: this bundle does NOT trip the B-01 pattern scanner (zero matches on all five patterns), so the override is not needed to install it. B-01 remains correct — it closed a real entrypoint-only coverage gap — but it isn't load-bearing here. verify-fixes.mjs now carries 36 assertions covering all three fixes, including source checks that fail if a guard is removed, if a legacy CBC OID reappears in the allowlist, or if the mail path stops using the native engine. Findings 4 (unlocked keys persisted to IndexedDB), 5 (parser DoS) and 6 (PKCS1v1.5 oracle surface) remain open. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com> |
||
|
Bernd RodlerandClaude Opus 4.8
|
f7e487171c |
security(smime): fork upstream plugin and fix two audit findings
S-01 audited bulwarkmail/plugins/smime @ 91085a3 (2,935 lines). Nine findings, two HIGH. No backdoor and no exfiltration path anywhere in the bundle — the problems are trust-model and input-validation gaps. Full report in vnc/audits/SMIME-PLUGIN-AUDIT-2026-08-04.md. Fork is source-only. The upstream smime.zip is a 1.77 MB prebuilt bundle whose manifest reads 1.0.1 while the source reads 1.0.2, so auditing src/ would not audit what that zip installs. We build from source. Finding 1 (HIGH) — certificate substitution. maybeAutoImportSigner gated on signatureValid alone, but smimeVerify runs checkChain:false, so that only proves "signed by whoever holds this key", not that the claimed identity is real. Self-sign a cert asserting victim@example.com, send one signed message, and it was stored as the encryption target for that address — the user's next Encrypt to the victim went to the attacker. Now requires signerEmailMatch === true and !selfSigned. Both values were already computed and displayed as untrusted in the banner; only the import path ignored them. Tests for `true` explicitly so an undefined match (missing From header) fails closed. Finding 3 (MED-HIGH) — CRLF header injection. Escaping reached only Subject and attachment filename; display names, raw addresses, Message-ID, In-Reply-To, References and attachment Content-Type were emitted verbatim, and formatAddress escapes only backslash and quote. In-Reply-To/References/display names are copied from inbound mail when replying or forwarding, so the value is attacker-supplied. Sanitising inside formatHeader covers all 17 call sites by construction; the three headers assembled directly get stripCrlf explicitly. Also adds auth:observe to the manifest. The plugin registers onAfterLogout/onAccountSwitch — real hooks (lib/plugin-hooks.ts:362-363) — without declaring the permission, so under B-09 the session-key wipe would silently stop running. verify-fixes.mjs carries 19 assertions including source checks that fail if either guard is removed or a new unsanitised interpolated header appears. That last one immediately caught the interpolated smime-type Content-Type header, which manual review had dismissed as static. Finding 2 (unauthenticated CBC accepted on decrypt) is NOT fixed. This is not safe for real mail yet — sandbox accounts only. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com> |