EVP_DecryptFinal_ex() called wc_ChaCha20Poly1305_Final() which only
computes the Poly1305 tag, writing it into ctx->authTag and
overwriting the expected tag stored there by EVP_CTRL_AEAD_SET_TAG.
No comparison was ever performed, so any forged tag was accepted.
Fix: save the expected tag before calling Final(), then verify with
wc_ChaCha20Poly1305_CheckTag() on the decrypt path, mirroring the
existing AES-GCM branch. Add a regression test that asserts
EVP_DecryptFinal_ex() rejects an all-zero forged tag.
Reported-by: Nicholas Carlini (Anthropic) & Bronson Yen (Calif.io)
wc_VerifyEccsiHash did not validate that r and s lie in [1, q-1]
after decoding them from the signature buffer. With s=0 the scalar
multiplication [s](...) returns the point at infinity (J_x=0); with
r=0 the final mp_cmp(0,0)==MP_EQ check then accepts the forged
signature unconditionally against any message and any identity.
Add [1, q-1] range checks for r (in wc_VerifyEccsiHash, after params
are loaded) and for s (in eccsi_calc_j, after eccsi_decode_sig_s),
mirroring the checks already present in wc_ecc_check_r_s_range.
Add a defense-in-depth point-at-infinity guard on J before the final
comparison.
Reported-by: Nicholas Carlini (Anthropic) & Bronson Yen (Calif.io)
The guard `if (cmac->totalSz != 0)` was used to skip XOR-chaining on
the first block (where digest is all-zeros and the XOR is a no-op).
However, totalSz is word32 and wraps to zero after 2^28 block flushes
(4 GiB), causing the guard to erroneously fire again and discard the
live CBC-MAC chain state. Any two messages sharing a common suffix
beyond the 4 GiB mark then produce identical CMAC tags, enabling a
zero-work prefix-substitution forgery. The fix removes the guard,
making the XOR unconditional; the no-op property on the first block is
preserved because digest is zero-initialized by wc_InitCmac_ex.
Identified by: Nicholas Carlini (Anthropic) & Thai Duong (Calif.io)
Make sure stack-allocated buffers containing potentially senstive
material are zeroized before function exit.
Identified by: Abhinav Agarwal (GitHub: @abhinavagarwal07)
In OpenSSL, ASN1_INTEGER is typedef'd to ASN1_STRING (same struct), so
calling ASN1_STRING_length() / ASN1_STRING_get0_data() on an
ASN1_INTEGER* is valid and well-defined. wolfSSL has them as distinct,
incompatible structs. This fixes the openvpn master failures introduced in
https://github.com/OpenVPN/openvpn/pull/1003
fixes and workarounds for clang-tidy complaints:
* clang-diagnostic-unknown-warning-option
* bugprone-sizeof-expression
* clang-diagnostic-error "address argument to atomic operation must be a pointer to a trivially-copyable type"
* bugprone-macro-parentheses
* clang-diagnostic-unused-but-set-variable
* readability-redundant-declaration
Tobias Frauenschläger
Daniel Pouzzner
Paul Adelsbach
JacobBarthelmeh
Marco Oliverio
lealem47
Lealem Amedie
Anthony Hu
Ruby Martin
Juliusz Sosinowicz
Josh Holtrop