Bug 2415863 (CVE-2025-13402) - CVE-2025-13402 github.com/rnpgp/rnp: RNP PKESK Session Keys Generated as All‑Zero
Summary: CVE-2025-13402 github.com/rnpgp/rnp: RNP PKESK Session Keys Generated as All‑...
Keywords:
Status: NEW
Alias: CVE-2025-13402
Product: Security Response
Classification: Other
Component: vulnerability
Version: unspecified
Hardware: All
OS: Linux
high
high
Target Milestone: ---
Assignee: Product Security DevOps Team
QA Contact:
URL:
Whiteboard:
Depends On: 2415865 2415866 2415867 2415868 2415869 2415870
Blocks:
TreeView+ depends on / blocked
 
Reported: 2025-11-19 13:39 UTC by OSIDB Bzimport
Modified: 2025-11-19 13:46 UTC (History)
0 users

Fixed In Version:
Clone Of:
Environment:
Last Closed:
Embargoed:


Attachments (Terms of Use)

Description OSIDB Bzimport 2025-11-19 13:39:37 UTC
today I stumbled upon a bug in RNP that has been introduced when refactoring. Namely, session keys generated for PKESK are not randomized but always zero. I believe this behaviour was introduced in https://github.com/rnpgp/rnp/commit/7bd9a8dc#diff-407f1b7227c5750de89205b12f416de7b215e3bb5e07c46daa25aff431654da2L993-R1041 Here, encrypted_build_skesk() will initialize the session key only for the SKESK case. For the PKESK case, the array remains all-zero. To confirm that the v0.18.0 release is affected, I built it and indeed, I can decrypt [typo corrected] PKESK-encrypted data when supplying the all-zero session key. Below are my steps to easily reproduce: git clone https://github.com/rnpgp/rnp.git cd rnp git checkout v0.18.0 git submodule update --init --recursive cmake -S . -B build/ cmake --build build/ -j6 mkdir /tmp/rnptmphome ./build/src/rnpkeys/rnpkeys -g --homedir /tmp/rnptmphome ./build/src/rnp/rnp --homedir /tmp/rnptmphome -es --armor version.txt Now one can use any utility to confirm the session key. For example, I went to https://dump.sequoia-pgp.org/, pasted version.txt.asc and put 0000000000000000000000000000000000000000000000000000000000000000 as session key. This will decrypt the data just fine.


Note You need to log in before you can comment on or make changes to this bug.