Crypt::Decrypt() calls "{name}Decrypt" with the algorithm name taken from the
token itself, so a client could ask for xxtea on any server. XxteaDecrypt used
$salt . Passphrase() as the key, but XXTEA reads only the first 16 bytes of its
key and the salt is 16 bytes stored in the token: the server secret never took
part. Anyone could therefore make a token every Crypt::Decrypt* consumer would
accept as genuine (remember-me, secure cookies, DecodeKeyValuesQ raw keys, ...),
and any real xxtea token could be read. The consumers traced so far still
require a server-side record or a real IMAP login, so this is not a known
account takeover, but the integrity check they rely on was not there.
- Decrypt refuses xxtea whenever sodium or openssl is available, i.e. whenever
Encrypt() would never have produced it, compares the name case-insensitively
(PHP method names are), and dispatches only sodium, openssl and xxtea rather
than any method name ending in Decrypt.
- The xxtea key is now the first 16 bytes of sha256(salt . passphrase), so on a
host left with nothing but xxtea it depends on the secret. Tokens written under
the old derivation stop decrypting there; they were never keyed by the server.
test/crypt-forgery.php forges a token with an attacker-chosen salt (accepted
before this change), checks it and an arbitrary method name are refused, and
that sodium, url-safe and xxtea round trips still work only with the right key.
The sanitizer sends img src, and url() in background-image, list-style-image
and content, through the remote content handling: blocked until the user
allows it, rewritten to the proxy when it is on. Two other ways to load an
image were left alone:
- srcset (and sizes) were on the attribute allowlist and never rewritten, so
<img srcset="https://..."> loaded when the message opened. With the proxy on,
the CSP keeps img-src to 'self', but a relative srcset="?/ProxyExternal/<b64>"
is same-origin and made the server fetch an attacker URL at render time: a
read receipt with no click. With the proxy off the browser fetched directly.
- url() in any other style property (border-image-source, mask-image, filter,
...) kept its value, with the same two outcomes.
Drop srcset and sizes from the allowlist (attributes not on it are deleted),
and remove any other style property whose value holds url(). Relative img src
was already safe: anything not cid:, http(s) or data:image/ is parked as
data-x-src-broken.
Checked the style sweep in Chromium: border-image-source, mask-image (both
spellings), filter and cursor lose the url(), other declarations survive, and
the background/list-style shorthands are left to the existing handling.
OpenSSL::verify() called openssl_pkcs7_verify with PKCS7_NOSIGS, which skips
the signature check, and returned success whenever that call did. Any
well-formed signed message therefore came back as success: true, including one
whose content had been changed after signing, and the client shows that as a
good signature (Message.js smimeSigned). Applies to the message view, the
explicit verify action and signed content inside decrypted mail.
The call is also how the content of an opaque signed message is extracted for
display, so it stays as it is for that, and a second openssl_pkcs7_verify
without PKCS7_NOSIGS now decides success and does not throw on failure. A
message with a broken signature remains readable but is no longer reported as
signed. PKCS7_NOVERIFY is kept on purpose: the signer certificate is not checked
against a CA, so success means the content is what the certificate holder
signed, not that the certificate is trusted; the comment says so.
test/smime-verify.php signs detached and opaque messages with a throwaway key,
checks the intact ones verify, and that altering one byte of signed content
flips success to false while the content stays readable. Before this change
the altered detached message was reported as validly signed.
DecodeHeaderValue removed CR and LF before decoding encoded-words, so an
encoded-word could still decode to a line break. A message whose Message-ID
was =?utf-8?b?...?= with CRLF inside reached the client with the break intact,
the client copies Message-ID into In-Reply-To when replying or forwarding, and
SetInReplyTo only trimmed it. The reply then carried header lines chosen by the
sender of the original, or a body if the payload held a blank line, sent and
DKIM-signed as the user and saved to Sent. Subject on Edit-as-new had the same
shape through the ASCII path.
Strip CR, LF and NUL in two places: after decoding in DecodeHeaderValue, and in
Header itself, which every outgoing header is built through, so a value that
arrives by another route (client parameters, plugins) cannot break the line
either. Folding is unaffected; __toString adds it back.
test/header-injection.php covers B and Q encoded-words, parsing, outgoing
In-Reply-To and Subject, and that long values still fold.
