It's precisely for the sake of code auditors that we *need* things like this. Personally, I am very interested in the results of this contest. Over the course of my career I have done audited for security hundreds of thousands of lines of code, and you know what, I have no idea how easy it is to deliberately hide malicious code from me. I have a few ideas on how it might be done, but there is always that nagging suspicion that somebody smarter than me could come up with something really clever and sneak flaws through an audit.

If there isn't an airing of malicious code obfuscation techniques in a public forum, then those techniques will never become publicly known, and those people trying to protect themselves from this sort of thing will continue to have no clue how to do so.

In code review, if I couldn't see myself writing code in the manner it's presented to me, I require an explanation until I can see myself writing code in that manner.
Anything complex is suspicious, unless I am taken from the original simple model to the complex one (and there'd better be a good reason for the complexity - sometimes it's only complex to understand, and is actually simpler code).
If I was to pick a favourite trick for getting bad code through a review, it would be to intersperse comments liberally through the code, and make the reader believe the comments over the code. That happens by accident so often that you quickly learn that comments are irrelevant.

Yeah, 10/10 for missing the point (and being behind the curve). This isn't just fun, it's educational. Understanding why such code is vulnerable leads to better security awareness.

People exploiting security vulnerabilities don't need this contest as much as the people who want to avoid making the 'mistakes' hidden in each entry. This is a way to show the technique without finding a vulnerability in deployed software.

Why don't you explain exactly how it's like playing Russian Roulette, rather than simply saying it's so and hoping to distract the militant people with gun references (statistically, the choice of gun doesn't improve the odds of surviving a shot to the head, by the way. Does the Magnum have fewer shots or something?). I try to choose blogs that give me insightful opinions, but there was nothing like that in this post; just a gut reaction that writing bad code is... bad. Oh well, my mistake. Unsubscribed.

I guess you're an advocate for absolute, total non-disclosure.

Sorry to hear you feel my opinion is off base James. I stick by it though. You missed my point of the post... which is the only good that will come of this is if code audit analysts learn from this to make their analysis efforts better. In other words, learn from it. Exactly what you are suggesting.

In the end though I come from the security engineering background. Rather than sitting and writing code to purposedly be evasive from analysis, I would rather see contests where people are given a problem and have to write code in a more defensive manner. I am tired of looking at code where very few error fault code paths are properly handled, where return codes are rarely checked, and code isn't designed to fail safely. I am sick of seeing poorly written code in generic try/catch exception blocks that actually do nothing to respond to failure, because they were never taught any different.

You are kidding yourself if you believe that techniques introduced in this content won't end up in future vulnerabilities relating to malware.

Since you have unsubscribed you won't see this anyways, but thats ok. For the rest of you who don't know, I do advocate RESPONSIBLE disclosure. I don't advocate disclosure for the sake of props or rep. And I don't care for contests to purposely write hostile code unless it is balanced with defensive coding measures as well. (aka Capture the Flag, which I rather enjoy)

There are more constructive ways that we can be educating the masses... this contest isn't needed. That said, we may as well leverage it now, and learn from it. The whole point of my post to begin with.

Dana, this isn't a disclosure issue in the usual sense of the word. RFP's responsible disclosure rules apply to vulnerabilities, not general techniques.

This is no different from McGraw and Hoglund writing a book on exploiting software flaws, or the NGS Software guys et al writing a book on writing shellcode. The basic assumption that the security world has to operate under is that the bad guys already know how to do everything. In practice that's probably not true, but defensive thinking requires that assumption to be made. People who assume that the bad guys *don't* know something are going to get burned for it sooner or later.

For those involved in cryptography, Kerkhoff's principle is founded on the same line of reasoning.

So, given the assumption we have to make, the onus is on the legitimate community to diffuse information as widely as possible amongst good guys. 'Underhanded' coding techniques should be posted widely for everyone to see. We are telling the bad guys something they may or may not already know, but we are telling good guys something they absolutely don't know. That's a net gain.

KB,

Fair enough points. I can't argue with what you are saying, as your position makes sense. I guess my beef is the fact so much effort and notice (aka media) is put on these contests, rather than on teaching people how to code more securely.

McGraw's book is a perfect example. I loved the "Exploiting Software" book. My only real criticism (outside of Hoglund's attitude) was the fact not enough was shown on how to DEFEND against such practices. Then Gary came out with "Software Security: Building Security In" where he does a ying/yang thing in showing attack/defense. (That reminds me, I still need to do a book review on that book... it's really that good!) To me, thats a much more productive way of going about educating the masses.

Thanks for the great insight.

I am smart auto posting. We are posting from auto machine.