On Tue, Dec 14, 2010 at 10:26:44PM -0500, Brandon Mercer wrote:

quoted text
> 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

quoted text
> Brandon
> On Dec 14, 2010 8:33 PM, "Damien Miller" <djm@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