6 ms·

Oh man: > I am bemused by an approach to accepting > security reports which is to go through the > motions of having PGP public keys available

by avar 10y ago

Oh man: > I am bemused by an approach to accepting > security reports which is to go through the > motions of having PGP public keys available > for people to use to report issues but upon > receiving such a request ask for it to be > submitted without PGP because digging out > the keys is too much of a hassle.

pm215 10y ago
Advertising that you use pgp and then in practice not using it is kind of daft, but is there actually much benefit to using encryption to initially report vulnerabilities?
- Godel_unicode 10y ago
  Using pgp is good for +30 cryptolluminati cool points. It also reduces your kibitz surface, which is useful for keeping the guardian from writing incorrect hit pieces about how you don't care about security. Other than that, not really.
- openasocket 10y ago
  If we're talking serious vulnerabilities (e.g. can allow remote code execution) for a project used by a large number of people, then absolutely. It can be weeks between initial report and a fix being pushed depending on the vulnerability, and even longer for people to update. It's a pretty good niche: intercept emails to maintainers for important projects and either sell the vulnerabilities or use them yourself in that small window. It'll net you a pretty steady stream of 0days if you can pull it off and you choose the right target. Encrypting communication makes that strategy a lot more difficult, and more invasive.
  - pm215 10y ago
    It just seems to me that the window is small (and you have to write a weaponised exploit in that time too), and the only people likely to be able to reliably intercept the email are nation-state actors who do bulk email slurping, and they're probably sitting on a pile of zerodays anyway. But that's just gut feeling so it's likely wrong.
    - openasocket 10y ago
      I'll admit it's not a likely scenario, it's just good trade craft. The window isn't as small as you'd think. The hacker would have all the malware written except for the infiltration point. And a skilled team, who is familiar with the software you are targeting, can go from a whitepaper to something actionable in a couple weeks. Less if they don't sleep much. Even better, a lot of these vulnerability reports come with POCs that can be pretty easily adapted to your needs. As for who could pull this off, you don't necessarily need nation-state resources. In fact, bulk email slurping probably wouldn't help, since STARTTLS is pretty ubiquitous. Since you're focusing on a single target, your best bet is compromising the SMTP server. If that's someone's personal server, that's well within the abilities of a moderately skilled group. If it's managed email (say gmail) it gets much harder, but maybe they get lucky and figure out your password, either from good guessing/brute force or from an account leak. Of course, a group could get access to those vulnerability reports by hacking the laptop of someone with the keys, but at least using PGP lowers the attack surface.
    - deleted 10y ago
      [deleted]
  - makomk 10y ago
    This is probably a niche use; all the potential RCE vulnerabilities I've found in projects with large numbers of users have involved projects with no formal vulnerability reporting process at all, where just finding a private way of reporting the issue was a pain.
clishem 10y ago
> Mind, we are overdue for some nice convenient tooling to have a PGP-decrypting-and-reencrypt-to-subscribers mailing-list software tool for use for such public contact points. We use this: https://github.com/fbb-git/gpg-remailer https://github.com/fbb-git/gpg-remailer
bradfitz 10y ago
I was the one who replied with that, asking him to resend without PGP, for two reasons: 1) both of our MTAs do STARTTLS. And gmail is only TLS. 2) 99% of the PGP-encrypted emails we get to security@golang.org are bogus security reports. Whereas "cleartext" security reports are only about 5-10% bogus. Getting a PGP-encrypted email to security@golang.org has basically become a reliable signal that the report is going to be bogus, so I stopped caring about spending the 5 minutes decrypting the damn thing (logging in to the key server to get the key, remembering how to use gpg). But I recognized him as a knowledgeable person from the Internet, and I knew (1), so I just asked him to send without PGP to save me 5 minutes. Even if I'd used PGP, I would've just replied cleartext anyway to our security@golang.org list, except all the MIME would've been garbled and unreadable. In summary, the PGP tooling sucks (especially in gmail, but really everywhere) and it's too often used by people who are more interested in using PGP than reporting valid security issues.
- syscomet 10y ago
  Those figures are both good and depressing to know, thanks. I figured the PGP usability problems were severe enough that I did not call you out by name in the post. This aspect was merely a darkly amusing aside leading into the main point of how the Golang devs handled this so well. You didn't know the content of the report, so the irony is only clear in retrospect: the whole point of the report was about vulnerability to MitM attack and email MX->MX delivery is highly susceptible to that without some kind of trust anchoring in place, whether DANE or MTA-STS, neither or which is in place for the golang.org domain. So the fact that TLS is _advertised_ by the gmail servers, which handle golang.org mail, doesn't mean that the advertisement reaches the sending mail-server. I've since configured my mail-servers to always require verified TLS for outbound mail to the golang.org domain, as a manual override.
  - bradfitz 10y ago
    I should update our docs to say: * If you can get remote code execution in a Go program, use PGP. Otherwise do not.
    - 10y ago

by avar 10y ago

pm215 10y ago

Advertising that you use pgp and then in practice not using it is kind of daft, but is there actually much benefit to using encryption to initially report vulnerabilities?

Godel_unicode 10y ago
Using pgp is good for +30 cryptolluminati cool points. It also reduces your kibitz surface, which is useful for keeping the guardian from writing incorrect hit pieces about how you don't care about security. Other than that, not really.
openasocket 10y ago
If we're talking serious vulnerabilities (e.g. can allow remote code execution) for a project used by a large number of people, then absolutely. It can be weeks between initial report and a fix being pushed depending on the vulnerability, and even longer for people to update. It's a pretty good niche: intercept emails to maintainers for important projects and either sell the vulnerabilities or use them yourself in that small window. It'll net you a pretty steady stream of 0days if you can pull it off and you choose the right target. Encrypting communication makes that strategy a lot more difficult, and more invasive.
- pm215 10y ago
  It just seems to me that the window is small (and you have to write a weaponised exploit in that time too), and the only people likely to be able to reliably intercept the email are nation-state actors who do bulk email slurping, and they're probably sitting on a pile of zerodays anyway. But that's just gut feeling so it's likely wrong.
  - openasocket 10y ago
    I'll admit it's not a likely scenario, it's just good trade craft. The window isn't as small as you'd think. The hacker would have all the malware written except for the infiltration point. And a skilled team, who is familiar with the software you are targeting, can go from a whitepaper to something actionable in a couple weeks. Less if they don't sleep much. Even better, a lot of these vulnerability reports come with POCs that can be pretty easily adapted to your needs. As for who could pull this off, you don't necessarily need nation-state resources. In fact, bulk email slurping probably wouldn't help, since STARTTLS is pretty ubiquitous. Since you're focusing on a single target, your best bet is compromising the SMTP server. If that's someone's personal server, that's well within the abilities of a moderately skilled group. If it's managed email (say gmail) it gets much harder, but maybe they get lucky and figure out your password, either from good guessing/brute force or from an account leak. Of course, a group could get access to those vulnerability reports by hacking the laptop of someone with the keys, but at least using PGP lowers the attack surface.
  - deleted 10y ago
    [deleted]
- makomk 10y ago
  This is probably a niche use; all the potential RCE vulnerabilities I've found in projects with large numbers of users have involved projects with no formal vulnerability reporting process at all, where just finding a private way of reporting the issue was a pain.

clishem 10y ago

> Mind, we are overdue for some nice convenient tooling to have a PGP-decrypting-and-reencrypt-to-subscribers mailing-list software tool for use for such public contact points. We use this: https://github.com/fbb-git/gpg-remailer https://github.com/fbb-git/gpg-remailer

bradfitz 10y ago

I was the one who replied with that, asking him to resend without PGP, for two reasons: 1) both of our MTAs do STARTTLS. And gmail is only TLS. 2) 99% of the PGP-encrypted emails we get to security@golang.org are bogus security reports. Whereas "cleartext" security reports are only about 5-10% bogus. Getting a PGP-encrypted email to security@golang.org has basically become a reliable signal that the report is going to be bogus, so I stopped caring about spending the 5 minutes decrypting the damn thing (logging in to the key server to get the key, remembering how to use gpg). But I recognized him as a knowledgeable person from the Internet, and I knew (1), so I just asked him to send without PGP to save me 5 minutes. Even if I'd used PGP, I would've just replied cleartext anyway to our security@golang.org list, except all the MIME would've been garbled and unreadable. In summary, the PGP tooling sucks (especially in gmail, but really everywhere) and it's too often used by people who are more interested in using PGP than reporting valid security issues.

syscomet 10y ago
Those figures are both good and depressing to know, thanks. I figured the PGP usability problems were severe enough that I did not call you out by name in the post. This aspect was merely a darkly amusing aside leading into the main point of how the Golang devs handled this so well. You didn't know the content of the report, so the irony is only clear in retrospect: the whole point of the report was about vulnerability to MitM attack and email MX->MX delivery is highly susceptible to that without some kind of trust anchoring in place, whether DANE or MTA-STS, neither or which is in place for the golang.org domain. So the fact that TLS is _advertised_ by the gmail servers, which handle golang.org mail, doesn't mean that the advertisement reaches the sending mail-server. I've since configured my mail-servers to always require verified TLS for outbound mail to the golang.org domain, as a manual override.
- bradfitz 10y ago
  I should update our docs to say: * If you can get remote code execution in a Go program, use PGP. Otherwise do not.
  - 10y ago