On 11 Oct 2012, at 17:14, Dennis E. Hamilton wrote: > @Nick > > I don't understand the supposed attack vector concerning the file digests > being of no value and the WoT being essential. > > - Dennis > > ANALYSIS > > So long as the digest value is obtained from a reliable read-only source, it > doesn't matter where the file comes from, the digest can be verified. This > will protect against and help detect a poisoned mirror site or a third-party > redistribution that substitutes an inauthentic artifact. That is, in fact, a > very big deal and it defends against exploits that happen too regularly.
In saying "a reliable read-only source, you're glossing over the MITM. My browser may say foo.apache.org when in fact it's talking to my evil ISP's proxy. > If the reliable read-only source is compromised, that means an adversary has > managed to (1) replace the file in Apache custody, and (2) replace the digest > that applies to that artifact. Yes, for those communicating directly with an apache server. We can improve the security of that using https, but that too is a weaker security model due not least to the variable quality of the CAs. > (Or just replace the digest and make the authentic file look bogus and the > poisoned downloads look authentic.) Funnily enough I diagnosed a rather similar issue for my mother only yesterday. A site at which she's shopped before had evidently been compromised, and the attacker had sent her email she took for genuine, while she was suspicious of a 'confirm your change of password' email that was almost certainly genuine (but useless). And the compromise had happened at least a month earlier, as evidenced by two monthly trojanised 'newsletter's from the attacker. Anecdotes aside ... > If substitution of the file-digest pair is achievable, providing a different > external signature can't be much harder, although the exploit might achieve > the intended purpose without that. Introducing a verifiable external > signature that finds a counterfeit public-key certificate on a key service > may extend the ruse a little longer. A trojan PGP key is plausible. Trojanised signatures are possible, though the bar seems to me to be rising. But a trojanised chain of trust leading back to a trusted signature? That raises the bar a long, long way. And within the ASF we have a lot of WOT interconnectedness: to impersonate an ASF key you'd need in effect to impersonate a whole lot of us. It's a many-eyes scenario, and those eyes will tend to route to tech-savvy brains. I'm at an advantage: when I download an Apache bundle, I can generally trace a chain of trust back to myself. If I find something signed by "Dennis E. Hamilton" but without enough ASF sigs to establish a chain of trust back to myself, I *will* query it, so an imposter is going to have hijacked your ASF email if (s)he's going to intercept my query and prevent you or me raising the alarm. Add to that other checks (e.g. does the project have an IRC channel, how old is the key and does that check out, if nothing checks out then ask the project dev list). Multiply that by lots of other folks who check PGP keys carefully, and that's a much higher level of security than some mere checksum. > The exploit continues until some Apache folk or security-proficient external > party detect (1) the substitution or (2) a counterfeit external signature or > (3) confirms that the external signature is not verifiable on the substituted > file and digest pair. Not "the signature" . A whole lot of signatures. Each with a real person to notice something is wrong, unlike an unowned checksum. > I don't see the WoT as much of a factor if this exploit occurs. It comes > down to how quickly the exploit is detected, the damage detected, and a > mitigation put in place. I assume that infrastructure defense-in-depth > measures have to expose the fact of an exploit, even if an insider is > involved. At the worst, it might be necessary to recall a release. > > This assumes that the exploit is by exploit against the read-only > distribution material in Apache custody. > > If the exploit is by tampering with a release prior to its approval, that is > an entirely different problem, Sure. If someone we elect as committer smuggles in a trojan, no amount of security after the event will help. That's a different issue to the one I thought we were talking about. -- Nick Kew --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
