On Tue, Dec 14, 2010 at 10:26:44PM -0500, Brandon Mercer wrote: > If this type of thing really did happen and this actually is going on > something as simple as systrace or dtrace would have found it correct? > Surely folks have monitored and audited the actual function and traffic that > goes across the wire... conversely amd has a "debugger" that'll get you > access to more goodies than you could imagine and just recently I discovered > a similar "debugger" on the wifi chip on my phone. Guess its better it > doesn't work anyhow ;)
It's generally impossible to see from a datastream if it leaks key data. It can be pretty damn hard to verify code to show it does not leak key data -Otto > Brandon > On Dec 14, 2010 8:33 PM, "Damien Miller" <d...@mindrot.org> wrote: > > On Tue, 14 Dec 2010, Bob Beck wrote: > > > >> I wonder a lot about the motives of the original sender sending that > message. > > > > Ignoring motive, and looking at opportunity: > > > > We have never allowed US citizens or foreign citizens working in the US > > to hack on crypto code (Niels Provos used to make trips to Canada to > > develop OpenSSH for this reason), so direct interference in the crypto > > code is unlikely. It would also be fairly obvious - the crypto code > > works as pretty basic block transform API, and there aren't many places > > where one could smuggle key bytes out. We always used arcrandom() for > > generating random numbers when we needed them, so deliberate biases of > > key material, etc would be quite visible. > > > > So a subverted developer would probably need to work on the network stack. > > I can think of a few obvious ways that they could leak plaintext or key > > material: > > > > 1. Ensure that key bytes somehow wind up as padding. This would be pretty > > obvious, since current IPsec standards require deterministic padding. > > Our legacy random padding uses arc4random_buf(). > > > > 2. Arrange for particular structures to be adjacent to interesting data, > > like raw or scheduled keys and "accidentally" copy too much. > > > > 3. Arrange for mbufs that previously contained plaintext or other > > interesting material to be "accidentally" reused. This seems to me the > > most likely avenue, and there have been bugs of this type found before. > > It's a pretty common mistake, so it is attractive for deniability, but > > it seems difficult to make this a reliable exploit. If I was doing it, > > I'd try to make the reuse happen on something like ICMP errors, so I > > could send error-inducing probe packets at times I thought were > > interesting :) > > > > 4. Introduce timing side-channel leaks. These weren't widely talked about > > back in 2000 (at least not in the public domain), but have been well > > researched in the years since then. We have already introduced > > countermeasures against the obvious memcmp() leaks using > > timingsafe_bcmp(), but more subtle leaks could still remain. > > > > If anyone is concerned that a backdoor may exist and is keen to audit the > > network stack, then these are the places I'd recommend starting from. > > > > -d