On Fri, Dec 24, 2010 at 07:27:02PM +0000, martin tarb wrote: > Theo de Raadt <deraadt <at> cvs.openbsd.org> writes: > > > > > > regarding the allegations about a backdoor beeing planted into OpenBSD, I > > > did a code review myself [...] > > > > By the way... > > > > It is unfortunate that it required an allegation of this sort for > > people to get to the point where they stop blindly trusting and > > instead go audit the code.... > > > > But looked at from the half-glass-full side, it is refreshing to see > > people trying! > > > > > Actually, when I would design such a backdoor, I wouldn't go for the item > getting highest attention and most difficult to crack. And because the crypto > stuff is getting most attention, it's highly likely it'll be replaced every > now > and then with something "better": Backdoor gone. > > I would do a "social engineering". Challenge the IPSec stack to tell me what I > want to know. > > How: > - Try to setup a connection with the server you want to have the keys from. > - Make a "failure" with this connection. > - This failure would use an additional parameter in the setup payload and > answer > with the info I want to have. > > So where to look: > In the state machine to initiate/setup the IPSec connection, especially the > error/declines it sends out. Things like: "setup failure, invalid key: > &(Yourkey+"additional parameter")". > > That'll be something very difficult to find in reviews (who does look at the > error notices, reviews are in general looking after the main functionality) > > Stack state machines tend to be related to the protocol basics and these don't > change, so it's very unlikely a backdoor like this is overruled by a "better" > implementation, especially if the original implementation is decent and > robust. > > This mechanism would need a handfull of connection setup attempts to get > everything you need to decompose a recorded stream. No intrusions will be > detected ever, unless logging is at debug level and who does wade through that > amount of logging ....... > > In some situations, you might need to be able to spoof the originating IP, > though having access to the network infrastructure itself, will be enough. > > Easy, hardly any code required, very difficult to detect and very likely to > survive for a long period.
Please also check what djm@ wrote in one of the first replies to Theo original mail: http://marc.info/?l=openbsd-tech&m=129237675106730&w=2 -Otto
