Hola, El 15/10/24 a las 23:07, Arturo Borrero Gonzalez escribió: > On 10/15/24 16:58, Santiago Ruano Rincón wrote: > > > > Moreover, I do see the code introduced by that change as part of > > 2:3.61-1+deb11u3, that relate to HACL* AVX2 support for different crypto > > algorithms. Could you please give more details about why do you say > > bullseye doesn't contain the affected code? > > > > Hi, thanks for the follow up > > Take this oneliner example: > > $ wget -O upstream_vulnerable.c > https://hg.mozilla.org/projects/nss/raw-file/d5deac55f54350d60fd6ae69899ac399fdfcfc72/lib/freebl/chacha20poly1305.c > && wget -O debian.c > https://sources.debian.org/data/main/n/nss/2%3A3.61-1%2Bdeb11u3/nss/lib/freebl/chacha20poly1305.c > && diff -u --color upstream_vulnerable.c debian.c > > This takes the file from the upstream code, just as it was when the > vulnerable code was introduced. Then, downloads the file from debian > 2:3.61-1+deb11u3. > > It is a big diff. > > Now this another oneliner: > > $ wget -O upstream.patch > https://hg.mozilla.org/projects/nss/raw-diff/525c5044cc9e53f5015c697b04b1405df91003ac/lib/freebl/chacha20poly1305.c
Have you checked in which branch commit 525c5044cc9e53f5015c697b04b1405df91003ac was applied to? > && wget -O debian.c > https://sources.debian.org/data/main/n/nss/2%3A3.61-1%2Bdeb11u3/nss/lib/freebl/chacha20poly1305.c > && patch -p1 debian.c < upstream.patch The patch cannot be applied like it is because of the differences between the code in bullseye (3.61), and the code the fixing commit mentioned above was prepared against. I haven't checked, but it was probably pushed to a more recent branch than NSS_3_61_BRANCH. In this case, backporting the related changes is necessary. E.g. is it enough to add the return to the avx2_support()-related conditional? > This takes the patch from the upstream repo, downloads the supposedly > vulnerable file from debian, then tries to apply the patch to the debian > file. > > Now yet another oneliner: > > $ wget -O upstream_3_61.c > https://raw.githubusercontent.com/nss-dev/nss/refs/heads/NSS_3_61_BRANCH/lib/freebl/chacha20poly1305.c > && wget -O debian.c > https://sources.debian.org/data/main/n/nss/2%3A3.61-1%2Bdeb11u3/nss/lib/freebl/chacha20poly1305.c > && diff -q upstream_3_61.c debian.c && echo "files are the same!" > > Upstream file in the 3.61 branch and the file in the debian bullseye > packages are the same. > > My interpretation from the above facts is: > * the upstream patch doesn't apply to the debian source I think that doesn't mean the present code in bullseye is not vulnerable. > * upstream vulnerable file and the file in debian are not the same > * the functions that the patch fixes (ChaCha20Xor and ChaCha20_Xor) don't > contain the same logic But part of it? Unfortunately, I don't have access to https://bugzilla.mozilla.org/show_bug.cgi?id=1905691, so I cannot tell you more details. I would ask input from upstream. > Therefore my conclusion: the vulnerability is not present in debian/bullseye IMO, that the patch that fixes the vulnerability doesn't cleanly apply is not enough condition to conclude the vulnerability is not present. Again, you can also ask upstream. They are in a better position to tell you if the vulnerability is present in 3.61 or not. > HOWEVER: > > If you clone the upstream git repo: > > $ git clone g...@github.com:nss-dev/nss.git > > Then checkout the branch: > > $ git checkout NSS_3_61_BRANCH > > The supposed change introducing the vulnerability is present: > > $ git log --decorate --oneline --graph lib/freebl/chacha20poly1305.c > * 9ff9d3925 Bug 1636771 - Fix incorrect call to Chacha20Poly1305 by PKCS11. > r=jcj,kjacobs,rrelyea > * d733ccc3a Bug 1623374 Need to support the new PKCS #11 Message interface > for AES GCM and ChaCha Poly > * 64ae3c81d Bug 1612493 - Support for HACL* AVX2 code for Chacha20, Poly1305 > and Chacha20Poly1305. r=kjacobs > > ^^^^ > > So, I wonder if the commit introducing the vulnerability has been > incorrectly identified? Where does that reference (the introducing commit) come from? > > I don't have a clear explanation at the moment of what is going on here :-( > As a general note: we prefer to err on the safe side (as the secteam does), which means to avoid marking a specific cve/package/release is not vulnerable unless we are not 100% sure of it. HTH, -- S
signature.asc
Description: PGP signature
