Hi! Thanks for reaching out and your contributions!
El 14/09/26 a las 11:19, Ivo Marino escribió: > Hi all, > > I'm a returning contributor (former NM applicant eim, advocated in > 2005, never finished the process, stepped away not long after) coming > back to Debian. Raphael suggested I introduce myself here directly > with real work rather than just asking questions, so here's where I > actually am. > > I don't have a Salsa account approved yet (request is still pending > review), so I can't push branches or open MRs myself. What is your Salsa account? Just in case: https://wiki.debian.org/Salsa/FAQ (But I'm not a salsa admin, so cannot directly help). > Both packages > below are fully backported, built, and tested against their real > bookworm source - I'd appreciate a review, and help getting them > uploaded, if someone has the time. > > == cjose (CVE-2026-53938, CVE-2026-53939) == > > Bookworm ships cjose 0.6.2.1-1, vulnerable to both. Two small patches, > DEP-3 headers included, both verified: applied cleanly against the > real 0.6.2.1-1 source, patched source builds, and I wrote a standalone > reproduction confirming the actual bug on unpatched source and the fix > on patched source (not just reading the commit messages). > > --- CVE-2026-53938.patch --- > Description: fix heap buffer overflow in AES key unwrap > _cjose_jwe_decrypt_ek_aes_kw() passed the attacker-controlled > encrypted_key straight to AES_unwrap_key() without checking its > length against the fixed-size jwe->cek buffer it unwraps into. A > crafted JWE with an oversized encrypted_key segment for an AES key > wrap algorithm (A128KW/A192KW/A256KW) triggers an out-of-bounds heap > write, which is at minimum a remote, unauthenticated denial of > service. Add the length check RFC 3394 already implies (wrapped key > length is always the plaintext CEK length plus 8 bytes) before > unwrapping. > Origin: upstream, https://github.com/OpenIDC/cjose/commit/8c51d2452 > Bug: https://github.com/OpenIDC/cjose/security/advisories > Forwarded: not-needed > Applied-Upstream: 0.6.2.5 > --- a/src/jwe.c > +++ b/src/jwe.c > @@ -587,6 +587,15 @@ static bool > _cjose_jwe_decrypt_ek_aes_kw(_jwe_int_recipient_t *recipient, cjose_ > return false; > } > > + // the wrapped key (RFC 3394) is always the plaintext CEK length > plus 8 bytes; > + // enforce this before calling AES_unwrap_key, which would > otherwise copy the > + // attacker-controlled encrypted_key into the fixed-size jwe->cek buffer > + if (recipient->enc_key.raw_len != jwe->cek_len + 8) > + { > + CJOSE_ERROR(err, CJOSE_ERR_INVALID_ARG); > + return false; > + } > + > // AES unwrap the CEK in to jwe->cek > int len = AES_unwrap_key(&akey, (const unsigned char *)NULL, > jwe->cek, (const unsigned char *)recipient->enc_key.raw, > recipient->enc_key.raw_len); > > --- CVE-2026-53939.patch --- > Description: fix all-zero content-encryption key for AES-CBC-HMAC > _cjose_jwe_set_cek_aes_cbc() passed the wrong boolean to > _cjose_jwe_malloc()'s "zero" parameter (inverted), so a freshly > generated CEK for AES-CBC-HMAC content encryption was always > zero-filled instead of randomly generated. Every JWE produced with > an AES-CBC-HMAC enc algorithm was therefore encrypted and > authenticated under the same fixed, publicly known key, letting > anyone who obtains such a JWE recover the plaintext and forge or > modify the content. > Origin: upstream, https://github.com/OpenIDC/cjose/commit/2a6e5bd96 > Bug: https://github.com/OpenIDC/cjose/security/advisories > Forwarded: not-needed > Applied-Upstream: 0.6.2.6 > > (Full patch, changelog stanza, and dla-needed.txt claim note ready - > happy to send whichever format is easiest to work with.) I think a full (signed) debdiff would be the most suitable here. As a side note, cjose is in dsa-needed.txt, and according to it, the security team is working on a trixie update. > > == git-lfs (CVE-2025-26625) == > > Bookworm ships git-lfs 3.3.0-1+deb12u1. git lfs checkout/pull wrote > object content via os.Create(), which follows a symlink at the target > path and truncates any hardlinked file in place instead of replacing > it - a crafted repository can make either command write outside the > working tree. Backported the full fix (not just the core issue): the > write-path fix itself, plus the two follow-up hardening commits > (checking intermediate path components for symlinks, and refusing to > run against a bare repository). One real adaptation needed: bookworm's > actual build toolchain is golang-1.19, which predates the stdlib > errors.Join the upstream hardening commit relies on - worked around > with a portable fmt.Errorf %w wrap instead, verified against upstream's > own (unmodified) test file. > > Verified twice: incrementally, then again applying the full patch > series from a pristine source extraction to confirm it works > standalone. go build and go test both clean both times. > > These patches are larger (one of them touches a new file plus five > existing ones) - I'll send them separately in whatever form's easiest, > rather than paste ~800 lines here. > > Let me know what you need from me to move either of these forward. Same, for the moment, a full debdiff is appreciated. FTR, CVE-2025-26625 was fixed in bullseye with DLA-4610-1. Your work is very opportune since there is currently an "apt-get dist-upgrade" regression, with the CVE still open in bookworm. We aim to avoid that kind of situations. If that is useful, you should be able to also find the bullseye update in the git repo: https://salsa.debian.org/go-team/packages/git-lfs/-/tree/debian/bullseye-security?ref_type=heads Thanks, -- Santiago
signature.asc
Description: PGP signature
