>I'm curious: how is the Linux development effort handling the
>danger that a contributor will build an undetectable security
>hole into his code? This is made much easier by the general
>nature of C and C++, and can be made arbitrarily hard to detect
>by scattering it among several different contributions by different
>people months or years apart.
in the sense that you've described it above, there's no defense in open
source to such a hole.
OTOH, "arbitrarily difficult to detect" is fundamentally different than
"undetectable". perhaps that's a semantic quibble, but the very fact that
the entire submitted source is available for inspection and detailed
analysis makes it as easy as possible to isolate and identify such a hole.
in practical terms, the limits on such an infiltration would be the
fluidity of the source itself, and the cost of introducing an arbitrarily
difficult hole.
splitting a back door among a dozen different pieces of code means that all
of those source files need to be present for the hole to work. the
openness of the source tree means there's no guarantee that any one
submission will remain in the tree for an extended period. the Linux tree
rotates /daily/. some little jerk may edit out one of your stealth
components and submit it as his own 'improvement' to the tree. for that
matter, the basic technology could shift (again) and the entire component
would be obsoleted before the entire hole is ready to roll.
assuming you /do/ build a hole into an open source system, you're unlikely
to use it much before someone decides there's sufficient reason to do a
detailed, arbitrarily high powered analysis of their security compromise.
it only takes one other person, somewhere on the internet, who's just as
clever as you are to isolate your hole and develop a remedy. again, the
openness of the source works against you, because it's tough to hide
something from an expert with a profiling compiler and stepwise debugger.
debugging can proceed in paralell, so for every expert at
reverse-engineering, there can be ten thousand amateurs doing brute-force
combinatorial recompilation of the source if people want to find your hole
badly enough. it doesn't matter how good you are, nobody wins a
butt-kicking contest against a mongolian horde.
judging by the history of the internet, the effective lifespan of such a
hole would be somewhere between a day and a week once you've really ticked
someone off.
the nature of software development makes it impossible to keep trojan
horses out of any source tree. i just don't know of any development model
which offers faster replication, isolation, remedy, and dissemenation
characteristics than open source. AFAIK, the default position in the OSS
community is that they welcome the opportunity to stomp bugs out as fast as
you can generate them.
mike stone <[EMAIL PROTECTED]> 'net geek..
been there, done that, have network, will travel.
____________________________________________________________________
--------------------------------------------------------------------
Join The Web Consultants Association : Register on our web site Now
Web Consultants Web Site : http://just4u.com/webconsultants
If you lose the instructions All subscription/unsubscribing can be done
directly from our website for all our lists.
---------------------------------------------------------------------
