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 ;)
Brandon
On Dec 14, 2010 8:33 PM, "Damien Miller" <djm@mindrot.org> wrote:
quoted text
> On Tue, 14 Dec 2010, Bob Beck wrote:
>
>> I wonder a lot about the motives of the original sender sending that
message.
quoted text
>
> 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