On Mon, Mar 17, 2008 at 1:10 PM, Andre Gironda <<a href="mailto:andre@operations.net">andre@operations.net</a>> wrote:<br><div class="gmail_quote"><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
On Mon, Mar 17, 2008 at 5:14 AM, nnp <<a href="mailto:version5@gmail.com">version5@gmail.com</a>> wrote:<br>
nnp,<br>
<br>
Thanks for focusing on the two issues from my email that I care the<br>
least about, but were most important for you to answer to appear<br>
intelligent compared to the rest of the group. Care to comment on any<br>
of the rest of my original post?<br>
<div class="Ih2E3d"></div></blockquote><div><br>Erm... if you don't care about the topics then why mention them in your post and take up two paragraphs to do so? Or is it that you just don't like it when people disagree with you? And no, I don't care to comment on the rest of your post because its not particularly interesting. The only reason I commented on the part I did is that you seem to have some misconceptions that I thought you might like cleared up.<br>
<br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><div class="Ih2E3d"><br>
> applications). Autodafe, GPF, Flayer, Bunny the Fuzzer etc. All these tools<br>
> are far more advanced than what is publicly available to do the same on<br>
> Windows. As for not targetting anything besides stack-based buffer<br>
> overflows, I think if you look at the fuzz strings people were using as far<br>
> back as SPIKE you can see strings for integer issues, unicode issues, format<br>
> string vulnerabilities, directory traversal, command execution and SQL<br>
> injection.<br>
<br>
</div>I'm familiar with all of these. That doesn't change my point. My<br>
point was that most testers are too specialized and obsessed with<br>
classic vulnerabilities/exploits on Windows.<br>
</blockquote><div><br>So evidence to the contrary doesn't change your opinion? Interesting.<br> <br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<br>
To further my point even more, all of the vulnerabilities/tools you<br>
named are still quite classic (and/or outdated). </blockquote><div><br>Outdated? Do you even know what those tools do or how they work? <br><br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
What about<br>
heap-based attacks, attacks on pipes, problems with signals, issues<br>
with time & state, </blockquote><div> <br>How are these types of attacks any less popular than stack based overflows? Just because all you or the people you surround yourself with only know/care about these issues doesn't mean everyone else does. A decent security auditor isn't going to have a 'favourite' bug class they only target. They will take whatever they can get. Also, could you please explain how fuzzing tools are more likely to target stack based overflows that heap based overflows? I'm really curious about that.<br>
<br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">as well as many of the other less-popular (or<br>
should I say less understood?) software weaknesses? I admit that<br>
traversals are interesting, but everything at the access level is<br>
relatively classic and played out. Most are just flatly "input<br>
validation" problems that can be tested for with unit testing.<br>
<div class="Ih2E3d"></div></blockquote><div><br>Indeed they can be. But then again, every exploitable bug class I can think of besides design level bugs can be tested for. The problem is, they aren't. Or it isn't done properly.<br>
<br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><div class="Ih2E3d"><br>
> > Does vulnerability research include exploit writing?<br>
><br>
</div>> I think it depends on your job. ... If you work<br>
<div class="Ih2E3d">> for a company that does security assessments or vulnerability research then<br>
> sometimes it can be difficult to convince the client that the issue you are<br>
> reporting is a) exploitable in the real world or b) a serious issue. In this<br>
> case an exploit can often get your point across easier than an argument.<br>
<br>
</div>I read in a book on "Secure Programming" once that this is the<br>
"Exploitability trap" and not to fall into it. I say go for the easy<br>
argument. Code is either obviously secure, ambiguous, or obviously<br>
insecure. If the code is obviously insecure or ambiguous - it must be<br>
made "obviously secure". Client still doesn't understand? Ask the<br>
client if they would like for you to outsource the writing of the<br>
exploit to a bunch of Chinese programmers you met on an underground<br>
forum or irc channel. I hear crowdsourcing is popular these days.<br>
<br>
Back to the original topic, I think that any new certifications will<br>
hurt us more than help. I think this because "security professionals<br>
/ vulnerability researchers" are already a bunch of white males with<br>
5-20 of information security experience and close to zero experience<br>
outside of our own industry. </blockquote><div><br>Nice generalisation there.<br> <br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Can we pigeon-hole ourselves and be<br>
over-specialized any more than we already are? Would this be a good<br>
thing?<br>
<br>
Cheers,<br>
<font color="#888888">Andre<br>
</font></blockquote></div><br><br clear="all"><br>-- <br><a href="http://www.smashthestack.org">http://www.smashthestack.org</a><br><a href="http://www.unprotectedhex.com">http://www.unprotectedhex.com</a>