As a followup, I have attached my draft DLA text, in case anyone has any feedback on it.
On 11/3/26 11:34, Simon Quigley wrote:
Hello, cjose 0.6.2.1-1+deb12u2 for bookworm-security is ready for review. The debdiff against 0.6.2.1-1+deb12u1 is attached. It carries the same two fixes DSA-6499-1 shipped in cjose 0.6.2.3-1+deb13u1 in Trixie, and cjose 0.6.2.8-1 in Sid has the same two commits: - CVE-2026-53938, https://github.com/OpenIDC/cjose/security/advisories/GHSA-75r7-f5cv-g3wj - CVE-2026-53939, https://github.com/OpenIDC/cjose/security/advisories/GHSA-f6wf-pqg3-6wqq Thanks to Ivo Marino, who posted the first Bookworm backport of these two to the list in September. The first one is a heap overflow. 0.6.2.1-1+deb12u1 copies an AES key wrap into a fixed buffer, so an oversized wrapped key writes past the end of it. deb12u2 checks the length first and returns an error if the wrapped key is too long. The second one is in the same 0.6.2.1 code. It fills the AES-CBC-HMAC content-encryption key with zeros, so two encryptions under the same wrapping key come out identical, and the payload ends up under a key anyone can know. With the fix, a fresh key is drawn every time, so two encryptions now come out different. Tokens made under the old all-zero key still decrypt, since that key rides along inside the token. The heap-overflow commit also touches CHANGELOG.md for a later release. I left the 0.6.2.1 release notes alone, and put the new test after test_cjose_jwe_decrypt_aes_gcm, which deb12u1 already has. For testing, I built this in a Bookworm schroot and also built both versions with AddressSanitizer. On deb12u1, the two AES-CBC-HMAC encryptions match, and a 64-byte wrapped key makes AES_unwrap_key write 56 bytes at the end of the 16-byte content-encryption key. That write is the wrapped length minus the 8-byte wrap overhead, so a 200-byte wrapped key is a 192-byte write of the same bug. On deb12u2, the encrypted keys differ and the oversized wrap comes back as CJOSE_ERR_INVALID_ARG. A token the older build encrypted with A128KW and A128CBC-HS256 still decrypts, and so does one it made with dir and A256GCM. The upstream suite runs 80 checks with 0 failures, both on the sanitizer build and on the sbuild binary, and a normal A128KW/A128GCM round trip works. libcjose0 0.6.2.1-1+deb12u1 has four reverse dependencies in Bookworm. I ran each of them in that schroot against both deb12u1 and deb12u2. libapache2-mod-auth-openidc 2.4.12.3-2+deb12u5 signs and verifies tokens, decrypts incoming JWE, and encrypts a request object. If you set the encryption algorithm and leave the content encryption empty, it picks A128CBC-HS256, which is the zero-key path. I built the Bookworm source and ran test/test (the same program make check runs), and with both libraries it printed "All 25 tests passed!" That run decrypts the AES key wrap and A128CBC-HS256 sample ("Live long and prosper."), decrypts the nested JWT, and signs and verifies an RS256 token. apache2ctl -M lists auth_openidc_module with both. liboauth2 1.4.5.4-1 encrypts with dir and A256GCM, and libapache2-mod-oauth2 3.3.1-1 reaches cjose through it. I built check_liboauth2 against the packaged liboauth2.so.0 and ran CK_RUN_SUITE=jose. With both libraries, the hash check, the symmetric-key check, encrypt, decrypt of the saved dir/A256GCM samples, the plain JWK check, and JWT verify all pass. test_jwks_resolve_uri fails on both, because it fetches http://127.0.0.1:8080/test/check_jose/jwks_uri and nginx on my machine already answers that port. apache2ctl -M lists oauth2_module with both. trafficserver-experimental-plugins 9.2.5+ds-0+deb12u4 (amd64 and arm64) links libcjose.so.0 from uri_signing.so, which signs and verifies JWS. I ran traffic_server from trafficserver 9.2.5+ds-0+deb12u4 on 127.0.0.1:18080, with uri_signing.so pointed at an HS256 key for issuer CDN and a local origin on 127.0.0.1:18081. With both libraries, a request with no token gets a 403, and one carrying URISigningPackage set to an HS256 JWS for that key gets a 200 with the origin body. ocserv 1.1.6-3 build-depends on libcjose-dev, and the Debian build leaves OpenID Connect auth at the upstream default (off), so the installed ocserv, ocserv-worker, ocpasswd, and occtl stop at their other libraries. To exercise the cjose path, I rebuilt the Bookworm source with --enable-oidc-auth and ran tests/test-oidc, which signs ES256 bearer tokens and posts them to a local ocserv. With both libraries, the good token gets a 200 and the twelve bad tokens get a 401. After the suite rotates the signing key, the old good token gets a 401 and a fresh one gets a 200. Here is the Salsa fork: https://salsa.debian.org/tsimonq2/cjose/-/tree/bookworm Here is the Debusine work request: https://debusine.debian.net/debian/developers/work-request/1578381/ Feedback is welcome. If nothing showstopping comes up, I'll upload this and issue the DLA on Saturday morning (November 7th, 2026). Best regards, Simon Quigley [email protected]
From: Simon Quigley <[email protected]> To: [email protected] Subject: [SECURITY] [DLA XXXX-1] cjose security update ------------------------------------------------------------------------- Debian LTS Advisory DLA-XXXX-1 [email protected] https://www.debian.org/lts/security/ Simon Quigley November 06, 2026 https://wiki.debian.org/LTS ------------------------------------------------------------------------- Package : cjose Version : 0.6.2.1-1+deb12u2 CVE ID : CVE-2026-53938 CVE-2026-53939 cjose is a C library implementing the Javascript Object Signing and Encryption (JOSE) standard. A remote attacker who can submit a JSON Web Encryption token to an application that decrypts it with AES key wrap can crash that application and corrupt its heap. When an application encrypts with an AES-CBC-HMAC content-encryption algorithm, anyone who obtains the token can read the payload and modify it, including a token already issued. CVE-2026-53938 Decrypting a JWE with A128KW, A192KW, or A256KW copied the encrypted key into a fixed-size content-encryption key with no length check. An oversized key writes past the end of that heap buffer. CVE-2026-53939 Encrypting a JWE with A128CBC-HS256, A192CBC-HS384, or A256CBC-HS512 filled the content-encryption key with zero bytes, for any key-management algorithm that generates a fresh key. For Debian 12 bookworm, these problems have been fixed in version 0.6.2.1-1+deb12u2. We recommend that you upgrade your cjose packages. For the detailed security status of cjose please refer to its security tracker page at: https://security-tracker.debian.org/tracker/cjose Further information about Debian LTS security advisories, how to apply these updates to your system, and frequently asked questions can be found at: https://wiki.debian.org/LTS
OpenPGP_signature.asc
Description: OpenPGP digital signature
