7 ms·

Spoofing OpenPGP.js signature verification

97 points by ThomasRinsma 1y ago

woodruffw 1y ago
Another year, another critical parsing vulnerability in the PGP ecosystem. Latacora has an excellent post[1] that touches on the excessive complexity of PGP's encoding which, remarkably, probably isn't even in the top 3 things wrong with PGP. My personal favorite of these is when someone sent a weaponized compression packet to oss-sec in 2022[2]. [1]: https://www.latacora.com/blog/2019/07/16/the-pgp-problem/ https://www.latacora.com/blog/2019/07/16/the-pgp-problem/ [2]: https://seclists.org/oss-sec/2022/q3/9 https://seclists.org/oss-sec/2022/q3/9
- upofadown 1y ago
  To save typing, I came up with a commentary on "The PGP Problem": * https://articles.59.ca/doku.php?id=pgpfan:tpp https://articles.59.ca/doku.php?id=pgpfan:tpp The complaint about excessive complexity was about the packet length representation. That isn't a really great example. The PGP packet length representation is fairly straightforward.
  - tptacek 1y ago
    You are writing this comment on a story where that packet format literally created a signature bypass vulnerability. Tell us more about how straightforward it is?
    - deknos 1y ago
      with that argument TLS would be insecure, because there are insecure TLS implementations.
      - pvg 1y ago
        That's not the argument, it's that it's a bad design repeatedly shown to be shown to be prone to serious vulnerabilities and it's silly to argue it's not a bad design at yet another such time. People have made serious arguments for all sorts of design problems in SSL/TLS.
        deknos 1y ago
        the design is not bad per se. pgp is just a bit outdated and needs an overhaul. And cryptographic serialization is just difficult.
        pvg 1y ago
        It's not resting, it's dead.
    - cbarrick 1y ago
      The issue discovered in TFA isn't about the format of individual packets (which "The PGP Problem" laments) but the grammar above the packets, i.e. the correct ordering of valid packets. Edit: foot successfully inserted in mouth
      - woodruffw 1y ago
        An absence of a canonical order or a definition of a well-formed packet sequence is itself a flaw in the packet format. Other cryptographic serialization and encoding schemes do not make this mistake.
        twiss 1y ago
        FWIW, OpenPGP does have a definition of a well-formed packet sequence, e.g. for messages here: https://www.rfc-editor.org/rfc/rfc9580.html#name-openpgp-messages https://www.rfc-editor.org/rfc/rfc9580.html#name-openpgp-mes... The packet sequence used by this vulnerability was not a valid OpenPGP message, as pointed out by the blog post (under the header "An invalid packet list"). Part of the issue in OpenPGP.js was that it didn't fully validate the message packet grammar, which has now been fixed: https://github.com/openpgpjs/openpgpjs/pull/1853 https://github.com/openpgpjs/openpgpjs/pull/1853
        tptacek 1y ago
        When we evaluate the design of a cryptosystem, we debit implementation vulnerabilities (at least in mainstream implementations) to the design. It is part of the goal of a cryptosystem design to foreclose on the possibility of implementation vulnerabilities.
        twiss 1y ago
        I would usually tend to agree with that, I was mainly just responding to the specific claim that OpenPGP doesn't have a definition of a well-formed packet sequence, which is false. Also, as a maintainer of OpenPGP.js, I'd say that while the complexity of OpenPGP certainly didn't help, quite a lot of things needed to go wrong to create this vulnerability: - The message grammar validation was incomplete, as mentioned - The streaming decryption/validation code affected how the packet sequence was processed - A later optimization when not streaming affected it further in a way that caused an inconsistency in which packets were being read when - Finally, the architecture of the code made it possible to return different data than what was verified, which should not have been possible (and we'll address this as well in a future refactor) All in all, I would place more of the "blame" on OpenPGP.js rather than OpenPGP. That being said, I don't think placing blame is the most important here; both OpenPGP.js and OpenPGP should and will learn from this.
  - woodruffw 1y ago
    You've linked this commentary in just about every PGP thread I've seen on HN, but the vulnerabilities keep coming. I don't think a dynamic TLV encoding was defensible a decade ago, and it certainly isn't defensible in 2025. (As the Latacora post points out, this is the same essential error that cryptographic applications of BER make. The difference is that serious users of ASN.1 have mostly sobered up and switched to DER; no such sobering has happened in the PGP ecosystem.)
tptacek 1y ago
This is not normal. Modern cryptosystems don't have anything like PGP's insane "packet" format, which has caused other problems before this. There's no principal of design that would lead you to what PGP came up with, and the only reason we still have to deal with it is path dependence. I don't even care if you call the next design "PGP2", just throw this system in the bin and start over.
- jcranmer 1y ago
  I'll admit that my knowledge of signed/encrypted email is mostly from S/MIME (and underlying CMS), so I'm curious if you could enlighten me on what PGP is doing that is so much more insane than that.
  - tptacek 1y ago
    I'm hanging back hoping 'woodruffw answers this so I don't have to. :)
  - woodruffw 1y ago
    Well, I don't know if I would call PGP so much more insane than CMS or PKCS#7 :-). Definitely worse, but CMS is not high up on the list of honorable cryptographic envelope designs. On the format level, CMS has some of the same flaws as PGP: dynamic TLV encodings (BER), extension points everywhere, and a disconnect between format and cryptographic versioning. On the cryptographic level, S/MIME benefits somewhat from certificates on the Internet PKI being less of a wild west than PGP certificates, and from having a community group (the S/MIME Cert WG of the CA/B Forum) invested in strengthening S/MIME's certificate profile beyond the baseline stipulated in RFC 5280. Of course, for non-public S/MIME deployments, none of that applies. All that said, I don't think I would treat S/MIME (or CMS, or PKCS#7) as a guiding star: EFAIL affected S/MIME too[1]. But they have the "advantage" of being bad at just their niche (signing and encryption of email), versus being bad at every niche. The latter is PGP's historic curse. [1]: https://efail.de/ https://efail.de/
    - jcranmer 1y ago
egberts1 1y ago
[flagged]

97 points by ThomasRinsma 1y ago

Another year, another critical parsing vulnerability in the PGP ecosystem. Latacora has an excellent post[1] that touches on the excessive complexity of PGP's encoding which, remarkably, probably isn't even in the top 3 things wrong with PGP. My personal favorite of these is when someone sent a weaponized compression packet to oss-sec in 2022[2]. [1]: https://www.latacora.com/blog/2019/07/16/the-pgp-problem/ https://www.latacora.com/blog/2019/07/16/the-pgp-problem/ [2]: https://seclists.org/oss-sec/2022/q3/9 https://seclists.org/oss-sec/2022/q3/9

upofadown 1y ago
To save typing, I came up with a commentary on "The PGP Problem": * https://articles.59.ca/doku.php?id=pgpfan:tpp https://articles.59.ca/doku.php?id=pgpfan:tpp The complaint about excessive complexity was about the packet length representation. That isn't a really great example. The PGP packet length representation is fairly straightforward.
- tptacek 1y ago
  You are writing this comment on a story where that packet format literally created a signature bypass vulnerability. Tell us more about how straightforward it is?
  - deknos 1y ago
    with that argument TLS would be insecure, because there are insecure TLS implementations.
    - pvg 1y ago
      That's not the argument, it's that it's a bad design repeatedly shown to be shown to be prone to serious vulnerabilities and it's silly to argue it's not a bad design at yet another such time. People have made serious arguments for all sorts of design problems in SSL/TLS.
      - deknos 1y ago
        the design is not bad per se. pgp is just a bit outdated and needs an overhaul. And cryptographic serialization is just difficult.
        pvg 1y ago
        It's not resting, it's dead.
  - cbarrick 1y ago
    The issue discovered in TFA isn't about the format of individual packets (which "The PGP Problem" laments) but the grammar above the packets, i.e. the correct ordering of valid packets. Edit: foot successfully inserted in mouth
    - woodruffw 1y ago
      An absence of a canonical order or a definition of a well-formed packet sequence is itself a flaw in the packet format. Other cryptographic serialization and encoding schemes do not make this mistake.
      - twiss 1y ago
        FWIW, OpenPGP does have a definition of a well-formed packet sequence, e.g. for messages here: https://www.rfc-editor.org/rfc/rfc9580.html#name-openpgp-messages https://www.rfc-editor.org/rfc/rfc9580.html#name-openpgp-mes... The packet sequence used by this vulnerability was not a valid OpenPGP message, as pointed out by the blog post (under the header "An invalid packet list"). Part of the issue in OpenPGP.js was that it didn't fully validate the message packet grammar, which has now been fixed: https://github.com/openpgpjs/openpgpjs/pull/1853 https://github.com/openpgpjs/openpgpjs/pull/1853
        tptacek 1y ago
        When we evaluate the design of a cryptosystem, we debit implementation vulnerabilities (at least in mainstream implementations) to the design. It is part of the goal of a cryptosystem design to foreclose on the possibility of implementation vulnerabilities.
        twiss 1y ago
        I would usually tend to agree with that, I was mainly just responding to the specific claim that OpenPGP doesn't have a definition of a well-formed packet sequence, which is false. Also, as a maintainer of OpenPGP.js, I'd say that while the complexity of OpenPGP certainly didn't help, quite a lot of things needed to go wrong to create this vulnerability: - The message grammar validation was incomplete, as mentioned - The streaming decryption/validation code affected how the packet sequence was processed - A later optimization when not streaming affected it further in a way that caused an inconsistency in which packets were being read when - Finally, the architecture of the code made it possible to return different data than what was verified, which should not have been possible (and we'll address this as well in a future refactor) All in all, I would place more of the "blame" on OpenPGP.js rather than OpenPGP. That being said, I don't think placing blame is the most important here; both OpenPGP.js and OpenPGP should and will learn from this.
- woodruffw 1y ago
  You've linked this commentary in just about every PGP thread I've seen on HN, but the vulnerabilities keep coming. I don't think a dynamic TLV encoding was defensible a decade ago, and it certainly isn't defensible in 2025. (As the Latacora post points out, this is the same essential error that cryptographic applications of BER make. The difference is that serious users of ASN.1 have mostly sobered up and switched to DER; no such sobering has happened in the PGP ecosystem.)

tptacek 1y ago

This is not normal. Modern cryptosystems don't have anything like PGP's insane "packet" format, which has caused other problems before this. There's no principal of design that would lead you to what PGP came up with, and the only reason we still have to deal with it is path dependence. I don't even care if you call the next design "PGP2", just throw this system in the bin and start over.

jcranmer 1y ago
I'll admit that my knowledge of signed/encrypted email is mostly from S/MIME (and underlying CMS), so I'm curious if you could enlighten me on what PGP is doing that is so much more insane than that.
- tptacek 1y ago
  I'm hanging back hoping 'woodruffw answers this so I don't have to. :)
- woodruffw 1y ago
  Well, I don't know if I would call PGP so much more insane than CMS or PKCS#7 :-). Definitely worse, but CMS is not high up on the list of honorable cryptographic envelope designs. On the format level, CMS has some of the same flaws as PGP: dynamic TLV encodings (BER), extension points everywhere, and a disconnect between format and cryptographic versioning. On the cryptographic level, S/MIME benefits somewhat from certificates on the Internet PKI being less of a wild west than PGP certificates, and from having a community group (the S/MIME Cert WG of the CA/B Forum) invested in strengthening S/MIME's certificate profile beyond the baseline stipulated in RFC 5280. Of course, for non-public S/MIME deployments, none of that applies. All that said, I don't think I would treat S/MIME (or CMS, or PKCS#7) as a guiding star: EFAIL affected S/MIME too[1]. But they have the "advantage" of being bad at just their niche (signing and encryption of email), versus being bad at every niche. The latter is PGP's historic curse. [1]: https://efail.de/ https://efail.de/
  - jcranmer 1y ago

egberts1 1y ago

[flagged]