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