Ethical Hacking

Learn to find vulnerabilities before the bad guys do! Gain real world hands on hacking experience in our state of the art hacking lab. Course designed and taught by expert instructors with years of penetration testing experience. 12 student maximum in every class. Certification attempt included in every package.
Computer Forensics Training at InfoSec Institute

Gain the in-demand skills of a certified computer examiner, learn to recover trace data left behind by fraud, theft, and cybercrime perpetrators. Discover the source of computer crime and abuse at your organization so that it never happens again. All of our class sizes are guaranteed to be 12 students or less to facilitate one-on-one interaction with one of our expert instructors.




Network Security Vuln-Dev
[Top] [All Lists]

RE: IE, Firefox, Opera DoS (*not* a DoS, not even close)

Subject: RE: IE, Firefox, Opera DoS (*not* a DoS, not even close)
Date: Thu, 26 Aug 2004 19:22:59 +0100 (BST)
 --- GulfTech Security <security@gulftech.org> wrote: 
 
Correct me if I am wrong, but isn't this just an
exhaustion of resources and
not a "vulnerability" at all? You could have it
write text to the page
instead of iframes and you get the same results
because the JavaScript goes
into an infinite loop.

Does having your 486 freeze up when you attempt to
open a 700mb DivX file
constitute as a vulnerability of the media software
or operating system? I
think not. Here is a "one liner" I wrote that does
the same thing, but I do
not in ANY way consider this a vulnerabity.

<script> var i = 1; while (i) </script>

James

To put it bluntly - you are not wrong. Exhaustion of
resources ~may~ seem to exhibit a DoS ie you cannot
use the "service" because it has been "denied" by the
effect of the cause of the deliberate exhaustion of
those same resources upon which the "service" depends.
FYI (and anyone else interested) I once wrote a
program to test dynamic runtime control creation when
I was getting into OOP VB; don't blame me, blame my
boredom ;)
The program opened with an initial form that had a
command button with 'Start' as its label. When you
clicked said button it would reproduce itself on
screen
using a loop to the effect of:
    Create form_object(my_form_class)
    Invoke form_object.show method
    Repeat ad infinitum
A windows message/spy tool I was running clocked up
~38000 before *itself* locked up (forms were still
being created) around 10 secs later the machine froze
until reboot.
Conclusion: malicious use (albeit only testing) of GUI
object creation thus exhausting GUI resourses thus
leading to lock up.
Lesson learned: *ANY* piece of software that uses data
as an input can be made to exhaust the resources given
to it by the OS if those same resources cannot handle
the extent of the size of that input whether it's a
huge file (usually in the order of GB/TB) or as a
series of object creations, as long as that series is
invoked to show on screen and not just in RAM waiting
to be used.
BTW for thosed that missed it the simple fix to my
program is to place a form_object.destroy (my wrapper
method names you understand) method call between
form_object.show and the end of the loop, thus getting
rid of the same object after it's been created
(freeing it's resources) but *before* another is.

Best regards
Steve






        
        
                
___________________________________________________________ALL-NEW Yahoo! 
Messenger - all new features - even more fun!  http://uk.messenger.yahoo.com

<Prev in Thread] Current Thread [Next in Thread>