Exploit

ImageMagick is a widely deployed, general purpose image processing library written in C. Over the past few years hundreds of security related issues have been identified. This paper considers one such instance of a remote code execution vulnerability discovered in 2016 under CVE-2016-3714. Introduction ImageMagick is a widely deployed, general purpose image processing library written in C, most commonly used to resize, transcode or annotate user supplied images on the web. Originally developed in 1987 and open sourced in 1990, with a large ecosystem of bindings for most programming languages, has established an enormous user base over the last 3 decades. ...

An evolution on basic stack smashing, return oriented programming (or ROP) was first presented by Solar Designer in 1997, as an innovative solution to crafting a complete program by daisy chaining up instructions that already exist within the address space of the program. Because existing legitimate executable instructions are chained together, is an effective way of bypassing non-executable stack (DEP) and code signing mitigations employed by most modern OS’s. An attacker gains control of the IP by overflowing the stack (i.e. buffer overflow or stack smash), to hijack program control flow and then executes carefully chosen machine instruction sequences that are already present programs address space. The individual pieces are known as gadgets. Each gadget typically ends in a return (RET) instruction. Chained together, these gadgets allow an attacker to perform arbitrary operations. ...

A popular buffer overflow prevention technique employed by some programs. Used to detect a stack buffer overflow before execution of malicious code can occur, by placing a small integer, the value of which is randomly chosen at program start, in memory just before the stack return pointer. Most buffer overflows overwrite memory from lower to higher memory addresses, so in order to overwrite the return pointer, the canary value must also be overwritten. This value is checked to make sure it has not changed before a routine uses the return pointer on the stack. This technique can greatly increase the difficulty of exploiting a stack buffer overflow because it forces the attacker to gain control of the instruction pointer by corrupting other important variables on the stack. ...

What’s a buffer overflow, and they can be exploited. Cover some prerequistite knowledge of (Intel x86) assembly and how a Von-Neumann machine works is needed. Attacking the stack is only one category of control flow attack, there are many others including heap allocators, race conditions, root exploits, ELF, networking, viruses, etc. The end game is to gain control of the instruction pointer (IP), and as a result contol flow of the program. But to set the scene, need to understand how this is even possible in the first place. All general purpose binary computers are bound by the laws of the turing machine, and its implementation architecture, the Von-Neumann design. ...

When you want to build and experiment with x86 (32-bit) based binaries on an x64 based linux kernel. This is often useful for reverse engineering and exploit proof of concepts, as x86 offers a number of simplicities over x64. On Kali (or I assume anything else debian based) add overall subsystem support with: dpkg --add-architecture i386 Then to get a working development environment: apt update apt install libc-dev-i386-cross gdb-multiarch execstack gdb-peda lib32tinfo6 lib32ncurses6 lib32ncurses-dev gcc-7 You should be good to start compiling for an x86 target. Make sure to add -m32 to any CFLAGS and LDFLAGS parameters in the Makefile. ...

A fundamental primer on exploit development on both Windows and Linux based OS’s. The classical classes of vulnerablilities: buffer overflow stack overflow heap overflow use after free out of bounds read Integer Overflow and NetBSD Considered concrete example in the NetBSD kernel, based on an incorrect coding style that is exposed to integer overflow during input validation. static int set_cursor(struct tfb_softc *sc, struct wsdisplay_cursor *p) { #define cc (&sc->sc_cursor) u_int v, index = 0, count = 0, icount = 0; uint8_t r[2], g[2], b[2], image[512], mask[512]; int error, s; v = p->which; if (v & WSDISPLAY_CURSOR_DOCMAP) { index = p->cmap.index; count = p->cmap.count; if (index >= 2 || (index + count) > 2) +++ integer overflow return (EINVAL); error = copyin(p->cmap.red, &r[index], count); if (error) return error; error = copyin(p->cmap.green, &g[index], count); if (error) return error; error = copyin(p->cmap.blue, &b[index], count); if (error) return error; Note the overflow, about 1/2 way down. Just imagine if index was a really large value that overflowed 32 bits. A more robust way to code the validation check, can be seen in the OpenBSD code: ...