Friday, December 23, 2011

Javascript setTimeout stop (clearTimeout)

I noticed a search query pointing to my site looking for how to stop a javascript setTimeout, and this is something I always forget. Here's the thing, when working with a timer, it emulates some form of multithreading/concurrency. Problems that can arise from this if you do things like timed animations on a triggered event are that if you don't stop a timer, you get multiple timers. This means at each trigger, you spawn a new timer to run with this emulated concurrency creating weird effects.

So to combat this, you want to use the method clearTimeout. This will take the argument of the integer returned when you call setTimeout. So when using this, you will also need to make sure you track that value.

var x = setTimeout(function() {
    alert("");
}, 1000);
clearTimeout(x);

This will appear not to do anything, but what it actually does is set the timer then clear it out. Now when you store the value, you can trigger an event to call the clearTimeout or you can initiate another setTimeout to have the clearTimeout run at some arbitrary time without a triggered event, like mathematically calculate a time to end some arbitrary animation without interrupting the main javascript code being executed or some such things. This method can also be called inside the timed function so long as it can clear the write variable, so make sure the scope is correct.

Monday, December 12, 2011

Javascript Exploit: setTimeout

When I was messing around with some javascript animation, I came across a rather strange exploit in javascript that can be taken advantage of to cause a little havoc on browsers. A quick explanation of javascript, when using an alert or other popup, that popup will pause the execution of the script until it is dealt with. However, setTimeout spawns another. This means using setTimeout, you can spawn multiple alert boxes or other such things that will pause and wait for input.

So then the question is how to use this to an exploit. A quick rough version would be something like
while (1){
  setTimeout(function (){
    alert("");
  }, 0);
}
This will create an infinite loop that will spawn alert boxes really fast, and probably freeze up or crash a browser. However due to browsers keeping javascript "sandboxed" for protection, there is a chance it will just say the script stopped responding and suspend it. This sandbox effect is to keep scripts from being able to interact with any other tabs or windows the user might have open as well as personal data stored, while not perfect, it can prevent certain exploits from causing damage.

Now alternatively, we could create a fork bomb. A fork bomb will multiply processes exponentially as apposed to what we have setup where it just increases directly. That will end up looking something like this.
function fork() {
  while (1){
    alert("");
    setTimeout(fork, 0);
  }
} fork();
This will then keep doubling but the effect will most likely be it just stops responding faster due to the sandbox setup. This could also have uses as this will fake multithreading by faking concurrency. So fake multithreading exploit is the bottom line.

Tag Cloud

.NET (1) A+ (2) addon (2) Android (2) anonymous functions (1) application (5) arduino (1) artificial intelligence (1) bash (2) camera (1) certifications (3) comptia (4) css (1) customize (8) encryption (1) error (11) exploit (4) ftp (1) funny (2) gadget (3) games (2) GUI (2) hardware (7) haskell (6) help (2) HTML (1) irc (1) java (2) javascript (11) Linux (13) Mac (3) malware (1) math (4) network (5) perl (2) php (3) plugin (2) programming (13) python (9) radio (1) regex (2) security (12) sound (1) speakers (1) ssh (1) story (1) Techs from the Crypt (2) telnet (1) tools (7) troubleshooting (3) Ubuntu (3) Unix (1) virtualization (1) web design (4) Windows (6) wx (1)