Instead of pointing flaws by "pros" without providing concise points, I will go ahead and:
@jakeem
https://cansecwest.com/slides/2015/Liang_CanSecWest2015.pdf
This is an example of a webkit exploit, the name convention is CVE-YYYY
the webkit is widely used as it is well popular worldwide, has source code, documentation AND fixes (this latter part describes how to trace stacks through a debugger)
An exploit of the webkit kind takes control of DOM objects at initialize->runtime, and background, a top - down operation (machine level) happens, done through a compiler, whose program data was already compiled (the nature of an exploit happens when the precompiled program flow causes indefined behaviour by not validating a process already statically revised, such as an invalid/unhandled instruction scheduling path (optimization for compilers) ).
https://en.wikipedia.org/wiki/Instruction_scheduling
There is usually the heap corruption + userland gaining of unprotected pointers to executable memory, such as VTABLES required by OOP (C++)paradigm compiler allocation methods.
Having control of a VTABLE pointer allows through userland to invoke objects to memory in trashed state (either unallocated, or re-allocated but casted as different object, leading to duplicate "allowed" pointers marked as read/writeables for a memory page marked as executable by the OS). This means you can pretty much write ROP code IN user space (machine assembly code it natively understands) + a nop slide/heap corruption, and hope for a processor exception to execute that certain area hand-crafted. This is how exploits begin.
To be honest I don't think the idea of google translate's (as it needs the text DOM at some point to override the length attribute, thus allocating more memory from heap) is far from good, it could even work!
Please refer to page 11:
tempa2.outerHTML="\n" marks the text parsed through DOM as freed memory, right after allocation. Causing an invalid pointer ready to be type-casted.
then later that copy to tempa2 (memory already freed) (const char*)"K33nTeam" causes an exception.
Page 16:
a2.innerHTML (casts an invalid, fake text object). When copying the text, DOM (and the beneath machine code) copies the whole TEXT object. By allocating new memory before the a2.innterHTML write takes place, THEN you copy over such TEXT object (casted by DOM), you get a controlled VTABLE (as in C++ paradigm), allowing to craft a fake VTABLE with ... ROP Code! Then just call the method by DOM, (relative by legit VTABLE start address + method size) for each method and signature, so fake VTABLE built allows you to call ROP -through-VTABLE allocation.
(VTABLE example, page 14)
(I was supposed to write toolchain/emu stuff but this hopefully allow newcomers to not get scared by more "experienced people" . Also, this deserved some background explanation to make sense, and to justify it as not a rant.)
@jakeem
https://cansecwest.com/slides/2015/Liang_CanSecWest2015.pdf
This is an example of a webkit exploit, the name convention is CVE-YYYY
the webkit is widely used as it is well popular worldwide, has source code, documentation AND fixes (this latter part describes how to trace stacks through a debugger)
An exploit of the webkit kind takes control of DOM objects at initialize->runtime, and background, a top - down operation (machine level) happens, done through a compiler, whose program data was already compiled (the nature of an exploit happens when the precompiled program flow causes indefined behaviour by not validating a process already statically revised, such as an invalid/unhandled instruction scheduling path (optimization for compilers) ).
https://en.wikipedia.org/wiki/Instruction_scheduling
There is usually the heap corruption + userland gaining of unprotected pointers to executable memory, such as VTABLES required by OOP (C++)paradigm compiler allocation methods.
Having control of a VTABLE pointer allows through userland to invoke objects to memory in trashed state (either unallocated, or re-allocated but casted as different object, leading to duplicate "allowed" pointers marked as read/writeables for a memory page marked as executable by the OS). This means you can pretty much write ROP code IN user space (machine assembly code it natively understands) + a nop slide/heap corruption, and hope for a processor exception to execute that certain area hand-crafted. This is how exploits begin.
To be honest I don't think the idea of google translate's (as it needs the text DOM at some point to override the length attribute, thus allocating more memory from heap) is far from good, it could even work!
Please refer to page 11:
tempa2.outerHTML="\n" marks the text parsed through DOM as freed memory, right after allocation. Causing an invalid pointer ready to be type-casted.
then later that copy to tempa2 (memory already freed) (const char*)"K33nTeam" causes an exception.
Page 16:
a2.innerHTML (casts an invalid, fake text object). When copying the text, DOM (and the beneath machine code) copies the whole TEXT object. By allocating new memory before the a2.innterHTML write takes place, THEN you copy over such TEXT object (casted by DOM), you get a controlled VTABLE (as in C++ paradigm), allowing to craft a fake VTABLE with ... ROP Code! Then just call the method by DOM, (relative by legit VTABLE start address + method size) for each method and signature, so fake VTABLE built allows you to call ROP -through-VTABLE allocation.
(VTABLE example, page 14)
(I was supposed to write toolchain/emu stuff but this hopefully allow newcomers to not get scared by more "experienced people" . Also, this deserved some background explanation to make sense, and to justify it as not a rant.)
Last edited by Coto,