Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Gpg.fail

gpg.fail

Post reply on HN
Print view View original

51–60 of 376 posts

Re: Gpg.fail

#51

Post by tptacek »

oefrha wrote: post #33

Okay, since there’s so much stuff to digest here and apparently there are issues designated as wontfix by GnuPG maintainers, can someone more in the loop tell us whether using gpg signatures on git commits/tags is vulnerable? And is there any better alternative going forward? Like is signing with SSH keys considered more secure now? I certainly want to get rid of gpg from my life if I can, but I also need to make sur…

One of those WONTFIX's is on an insane vulnerability: you can bitflip known plaintext in a PGP message to switch it into handling compression, allowing attackers to instruct GnuPG packet processing to look back to arbitrary positions in the message, all while suppressing the authentication failure message. GPG's position was: they print, in those circumstances, an error of some sort, and that's enough. It's an attack that reveals plaintext bytes!

Re: Gpg.fail

#52

Post by akerl_ »

xorcist wrote: post #48
akerl_ wrote: post #44

Earlier quoted context omitted.

A huge part of GPG’s purported use case is getting a signed/encrypted/both blob from somebody and using GPG to confirm it’s authentic. This is true for packages you download and for commits with signatures. Handling untrusted input is core to that.

It is, and other software handling untrusted data should also treat it as adversarial. For example, your package tool should probably not output raw package metadata to the terminal.

I think you’re missing the forest for the trees.

Re: Gpg.fail

#53

Post by perching_aix »

singpolyma3 wrote: post #49
perching_aix wrote: post #47

Earlier quoted context omitted.

What are those better tools? I've been broadly looking into this space, but never ventured too deep.

Sequoia for example has been doing a great job and implements the latest version of the standard which brings a lot of cryptography up to date

I'm yet to finish watching the talk, but it starts with them confirming the demo fraudulent .iso with sequoia also (they call it out by name), so this really makes me think. :)

Re: Gpg.fail

#54

Post by LtWorf »

woodruffw wrote: post #25
LtWorf wrote: post #23

Earlier quoted context omitted.

Well python discarded signing entirely so that's one way to solve it :)

Both CPython and distributions on PyPI are more effectively signed than they were before. (I think you already know this, but want to relitigate something that’s not meaningfully controversial in Python.)

Being signed by some entity which is not the author is hardly more effective.

(I think you already know this as well)

Re: Gpg.fail

#55

Post by arccy »

perching_aix wrote: post #47
cpach wrote: post #20

Earlier quoted context omitted.

To be frank, at this point, GPG has been a lost cause for basically decades. People who are serious about security use newer, better tools that replace GPG. But keep in mind, there’s no “one ring to rule them all”.

What are those better tools? I've been broadly looking into this space, but never ventured too deep.

ssh or minisign for signing age for file encryption

Re: Gpg.fail

#56

Post by oskarw85 »

tptacek wrote: post #39

A thru-line of some of the gnarliest vulnerabilities here is PGP's insane packet system, where a PGP message is a practically arbitrary stream of packets, some control and some data, with totally incoherent cryptographic bindings. It's like something in between XMLDSIG (which pulls cryptographic control data out of random places in XML messages according to attacker-controlled tags) and SSL2 (with no coherent authent…

Thank you for this excellent explanation!

Re: Gpg.fail

#57

Post by woodruffw »

LtWorf wrote: post #54
woodruffw wrote: post #25

Earlier quoted context omitted.

Both CPython and distributions on PyPI are more effectively signed than they were before. (I think you already know this, but want to relitigate something that’s not meaningfully controversial in Python.)

Being signed by some entity which is not the author is hardly more effective. (I think you already know this as well)

It is, in fact, signed by the author. It's just a PKI, so you intermediate trust in the author through an authority.

This is exactly analogous to the Web PKI, where you trust CAs to identify individual websites, but the websites themselves control their keypairs. The CA's presence intermediates the trust but does not somehow imply that the CA itself does the signing for TLS traffic.

Re: Gpg.fail

#58

Post by tptacek »

perching_aix wrote: post #53
singpolyma3 wrote: post #49

Earlier quoted context omitted.

Sequoia for example has been doing a great job and implements the latest version of the standard which brings a lot of cryptography up to date

I'm yet to finish watching the talk, but it starts with them confirming the demo fraudulent .iso with sequoia also (they call it out by name), so this really makes me think. :)

Sequioa hasn't fixed the attack from the beginning of the talk, the one where they convert between cleartext and full signature formats and inject unsigned bytes into the output because of the confusion.

Re: Gpg.fail

#59

Post by ameliaquining »

perching_aix wrote: post #47
cpach wrote: post #20

Earlier quoted context omitted.

To be frank, at this point, GPG has been a lost cause for basically decades. People who are serious about security use newer, better tools that replace GPG. But keep in mind, there’s no “one ring to rule them all”.

What are those better tools? I've been broadly looking into this space, but never ventured too deep.

https://www.latacora.com/blog/2019/07/16/the-pgp-problem/#th... lists a bunch of them.

Re: Gpg.fail

#60

Post by ameliaquining »

elric wrote: post #13

This is depressing. From what I can piece together while the site is down, it seems like they've uncovered 14 exploitable vulnerabilities in GnuPG, of which most remain unpatched. Some of those are apparently met by refusal to patch by the maintainer. Maybe there are good reasons for this refusal, maybe someone else can chime in on that? Is this another case of XKCD-2347? Or is there something else going on? Pretty m…

If by "pretty much every Linux distro depends on PGP being pretty secure" you're referring to its use to sign packages in Linux package managers, it's worth noting that they use PGP in fairly narrowly constrained ways; in particular, the data is often already trusted because it was downloaded over HTTPS from a trusted server (making PGP kind of redundant in some ways). So most PGP vulnerabilities don't affect them.

If there were a PGP vulnerability that actually made it possible to push unauthorized updates to RHEL or Fedora systems, then probably IBM would care, but if they concluded that PGP's security problems were a serious threat then I suspect they'd be more likely to start a migration away from PGP than to start investing in making PGP secure; the former seems more tractable and would have maintainability benefits besides.

Post reply on HN