[OWASP-TESTING] Application DoS Section

Mauro Bregolin mauro.bregolin at gmail.com
Tue Sep 6 10:39:04 EDT 2005


I agree on what you're saying, and in fact it might not be beneficial to
modify the whole document.
However, while causing a DoS might be pointless in the scope of testing,
citing DoS as a possible outcome of an attack might have some value, if not
for the reason that you might cause a DoS yourself when testing.
It is true that this is more likely with some vectors (e.g., malfunctioning
BOFs) than others, where you have to do it purposefully. SQL injection
probably is of the latter kind; though, if you can play with UPDATE commands
you can do quite some harm and one could argue that if you don't know the
internal semantics you might inadvertently cause unintended damage and
consequently DoS.
Hope it doesn't appear too confusing...


-----Original Message-----
From: owasp-testing-admin at lists.sourceforge.net
[mailto:owasp-testing-admin at lists.sourceforge.net] On Behalf Of Shields,
Sent: martedì 6 settembre 2005 14.56
To: Javier Fernandez-Sanguino
Cc: owasp-testing at lists.sourceforge.net
Subject: RE: [OWASP-TESTING] Application DoS Section

I think the difference might be that the DoS in a Buffer Overflow comes
before the "real" exploit of command execution.  I've covered it in the
existing chapter I've written.  But in the case of something like
"dropping all the tables from the database", that can only happen once
you're successfully exploiting SQL Injection attacks at will.  For
example, will the Authentication section have a part that notes you can
use SQL injection to add a fake account to accounts table in the
database?  Will an authorization section note that you can use SQL
injection to add permissions to the permission table?  The list sorta
goes on.  Once you have a working remote exploit such as command
execution or SQL injection stuff, there are a huge number of possible
vectors.  I don't know that I'm convinced that it's wise to try and put
stuff into every other security chapter that addresses things that
people using other exploits could do after they've owned the box.  After
all, that's not really "testing" at that point, so much as causing
further damage once in.  I guess if you *really* needed to prove that
having root on a server or admin command access in the database is bad
to someone, it might be useful, but... 

Still, I'll defer to what people want to do here.  But just about every
section will need to address these vectors...


-----Original Message-----
From: Javier Fernandez-Sanguino [mailto:jfernandez at germinus.com] 
Sent: Monday, September 05, 2005 5:30 AM
To: Shields, Larry
Cc: owasp-testing at lists.sourceforge.net
Subject: Re: [OWASP-TESTING] Application DoS Section

Shields, Larry wrote:

> However, by this same logic, one could put the Buffer Overflow DoS 
> into that same type of category.  So I'm willing to listen to opinions

> from others on this... Do we want to include a catch-all of other 
> possible ways someone could make the application unavailable if they 
> used other attacks to compromise something in the application, like 
> those we discussed here?

Yes, I think that's best. Notice that a buffer overflow might not
inmediately lead to code execution but can lead to a DoS (consider an
application running on an obscure processor or a known vulnerability
with no exploit code: you can find a buffer overflow in an obscure
application (by simpkly feeding long parameter values) but he might not
be able to debug the application in place in order to determine how to
setup the buffer overflow to execute code.



SF.Net email is Sponsored by the Better Software Conference & EXPO
September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf
owasp-testing mailing list
owasp-testing at lists.sourceforge.net

More information about the Owasp-testing mailing list