I followed a lot of tutorials about the exploitation of UAF vulnerabilities, but there was never explained how to find and detect UAF vulnerabilities in JavaScript or HTML (i.e. with a static analysis).

My question is: how to reverse engineer JavaScript functions to see if an object was freed, by this function, and with which function I can use it again (after it was freed) to provoke a use after free issue?

  • 1
    Stop it already with your "sorry for my English, I'm German". Also, you might not want to hear that but your question makes no sense. JavaScript is a scripting language that often relies on open source interpreters. So all the source code is there, you needn't reverse engineer. Also, if those problems could be found with static analysis, they wouldn't (or at least shouldn't) be there in the first place. – Tobi Nary Mar 26 '16 at 12:21
  • Let me add that finding and exploiting a use-after-free vulnerability is not a simple task. You need to be an experienced software developer who understands the memory models of various programming languages as well as of the computer. Without that knowledge, it is not likely that any number of questions on websites will help you. Go take a year or two to deepen your computer science and programming skills and then you'll be able to see why finding UAF vulnerabilities is so difficult. – Neil Smithline Mar 26 '16 at 16:20
  • You are right, my question makes no sense and after I done a research about finding uaf vulnerabilities in javascript, I usually got no answer. But when I sought for detecting uaf vulnerabilities on binary code I found this paper and I unterstood it: google.de/… – user104787 Mar 26 '16 at 17:38

Although JavaScript and HTML as languages are free from use-after-frees by design (due to the lack of low-level memory access), they can still be used to exploit UAF in the engines that interpret and run JavaScript/HTML.

This is how you find UAF vulnerabilities:

  1. Provide an input that causes the application to crash or misbehave. E.g. by fuzzing or an educated guess based on the analysis of the program.
  2. Reduce the input to a minimal example that causes the crash.
  3. Investigate why the sample triggers a crash. E.g. by stepping through with a debugger, or by studying the source code. The most prominent examples of applications that interpret JavaScript are web browsers, and the popular ones are open-source (ChakraCore for Microsoft Edge. V8/Chromium, Firefox) (all using C++), which makes this step easier.

To get started, you can study public bug reports (e.g. Chrome's medium/high/critical severity bugs (severity guidelines), Firefox's high/critical bugs (severity guidelines), any CVE). JavaScript is a highly dynamic language, sometimes you can do things that the designers/implementers of a certain feature did not intend or expect, resulting in security vulnerabilities (e.g. a JSON serializer that did not account for the fact that custom callbacks can modify the input). Most of the bugs are not in the JavaScript engine itself, but in the implementation of the available APIs (e.g. DOM is not part of JavaScript).

If available, use AddressSanitizer because it makes it easier to detect and classify the type of memory bug. You can either build it from source, or use the pre-built binaries (see e.g. Firefox or Chrome).

Note: Finding the UAF is the easiest step, actually exploiting it is much more difficult. Modern programs use all sorts of preventive measures to counter vulnerabilities (e.g. ASLR, non-executable stacks, stack/heap protectors, and more).

| improve this answer | |

Your question is incorrect on many levels.

First, JavaScript is memory managed language. That is, a developer never actually frees memory. Instead, the JavaScript interpreter manages all of that. So, if the JavaScript interpreter is written correctly, there can be no use-after-free vulnerabilities. As such, static analysis of JavaScript will never find a use-after-free vulnerability.

HTML doesn't really have a concept of memory management to even discuss use-after-free.

As far as reverse engineering JavaScript functions, that doesn't really make sense. JavaScript is not compiled so you always have the source available. Perhaps the JavaScript was obfuscated, but you still have the code, it's just hard to read.

| improve this answer | |

Not the answer you're looking for? Browse other questions tagged or ask your own question.