I think all in all That it should be considered!<br><br>On 5/1/07, Steven Adair <<a href="mailto:steven@securityzone.org">steven@securityzone.org</a>> wrote:<br>> I think a good share of the time when someone states that the DoS may
<br>> "possibly" lead to remote code execution are making such a statement for a<br>> couple different reasons:<br>> <br>> 1) They found a DoS and truly have no idea whether or not it can cause<br>> remote code execution due to not having the knowledge/skills necessary to
<br>> check for it and/or lack of time to make such a determination.<br>> <br>> 2) They have seen characteristics that would indicate that remote code<br>> execution is possible but have not quite been able to nail down a working
<br>> exploit "should" one be possible.<br>> <br>> I do not think the evidence quickly available to us would bring us to<br>> conclude most DoS's end up resulting in remote code execution -- or even
<br>> have the ability to. I would agree saying "often enough" would be better<br>> than "most."<br>> <br>> However, regardless of whether it results in remote code execution, I<br>> don't think a DoS should necessarily be discounted as frivolous or
<br>> irrelevant. It might not rank up there with critical or high<br>> vulnerabilities, but it is a vulnerability nonetheless.<br>> <br>> Steven<br>> <a href="http://securityzone.org">securityzone.org</a>
<br>> <br>> > Ok 'most' is probably bad wording on my part how does 'often enough' sound<br>> > :).<br>> ><br>> > "Buffer overflow in the png_decompress_chunk function in pngrutil.c
in<br>> > libpng before 1.2.12 allows context-dependent attackers to cause a<br>> > denial of service and possibly execute arbitrary code"<br>> > <a href="http://www.securityspace.com/smysecure/catid.html?id=57643">
http://www.securityspace.com/smysecure/catid.html?id=57643</a><br>> ><br>> > "Buffer overflow in efingerd 1.5 and earlier, and possibly up to 1.61,<br>> > allows remote attackers to cause a denial of service and possibly
<br>> > execute arbitrary code via a finger request from an IP address with a<br>> > long hostname that is obtained via a reverse DNS lookup."<br>> > <a href="http://cve.mitre.org/board/archives/2003-03/msg00013.html">
http://cve.mitre.org/board/archives/2003-03/msg00013.html</a><br>> ><br>> > "A BrightStor ARCserve Backup contains four<br>> > vulnerabilities that can allow a remote attacker to cause a denial<br>> > of service or possibly execute arbitrary code."
<br>> > <a href="http://packetstorm.linuxsecurity.com/0703-advisories/CAID-McAfee.txt">http://packetstorm.linuxsecurity.com/0703-advisories/CAID-McAfee.txt</a><br>> ><br>> ><br>> > Note the use of 'possibly'. If it was possible then 'possibly' wouldn't be
<br>> > used.<br>> ><br>> > I'm not going to debate the validity of the month of activex bugs because<br>> > frankly I don't care, merely<br>> > that a DOS can turn out to be more and that at times either the researcher
<br>> > hasn't spent enough time on it, can't get the POC working, or lacks the<br>> > skill to fully understand the problem.<br>> ><br>> > There have been multiple instances on the securityfocus lists throughout
<br>> > the years where a DOS suddenly<br>> > became promoted to a remotely exploitable bug (i.e another person found it<br>> > was actually exploitable). I'm not going<br>> > to find them and post them here, but a little googling can yield
<br>> > results.<br>> ><br>> > - Robert<br>> > <a href="http://www.cgisecurity.com/">http://www.cgisecurity.com/</a><br>> ><br>> >> >>Consider that most often a bug filed as DOS can actually be
<br>> >> exploitable, but the person who discovered it can't get the POC working<br>> >> or is even aware it is. While command execution is the ideal goal it<br>> >> doesn't mean other types of issues are *completely* worthless. =20
<br>> >><br>> >> Most often? How do you know that?<br>> >><br>> >> Larry Seltzer<br>> >> eWEEK.com Security Center Editor<br>> >> <a href="http://security.eweek.com/">
http://security.eweek.com/</a><br>> >> <a href="http://blogs.eweek.com/cheap_hack/">http://blogs.eweek.com/cheap_hack/</a><br>> >> Contributing Editor, PC Magazine<br>> >> larryseltzer@ziffdavis.com
=20<br>> >><br>> ><br>> > _______________________________________________<br>> > Full-Disclosure - We believe in it.<br>> > Charter: <a href="http://lists.grok.org.uk/full-disclosure-charter.html">
http://lists.grok.org.uk/full-disclosure-charter.html</a><br>> > Hosted and sponsored by Secunia - <a href="http://secunia.com/">http://secunia.com/</a><br>> ><br>> <br>> <br>> _______________________________________________
<br>> Full-Disclosure - We believe in it.<br>> Charter: <a href="http://lists.grok.org.uk/full-disclosure-charter.html">http://lists.grok.org.uk/full-disclosure-charter.html</a><br>> Hosted and sponsored by Secunia -
<a href="http://secunia.com/">http://secunia.com/</a><br>> <br><br><br>-- <br><a href="http://www.goldwatches.com/watches.asp?Brand=39">http://www.goldwatches.com/watches.asp?Brand=39</a><br><a href="http://www.wazoozle.com">
http://www.wazoozle.com</a><br>