Heap Linux
Linux Heap Exploitation Intro Series: Set you free() – part 2
Intro Hello there! On this part we are focusing on abusing chunk creation and heap massaging in hope of overwriting the __malloc_hook weak pointer. Before getting into all the juicy stuff let’s remember some key things from last post.
The value returned by png_get_uint_32 is of type unsigned integer For a 32 bit integer, the following happens: 0xffffffff + 1 = 0 fread will read values into the destination unless it can’t read from source memory (spoiler: it can) fread will return the number of elements read from the source Points 1 and 2 were made clear but 3 and 4 were left unanswered.
Linux Heap Exploitation Intro Series: Set you free() – part 1
Intro (part 1) Hello and welcome to the final post of our Intro to exploitation series! We have learned the basics about how the memory management as per the ptmalloc2 allocator works. It was a basic but enough approach to have a good starting point. However, there are a few concepts and attack scenarios that, due to existing a lot of information about these, I have kept long distance from “unsafe unlink“, “malloc (des)malleficarum” and techniques alike. These weren’t either basic enough or outdated and wanted to learn and note down the most basic and known exploit primitives: Use-after-invalidation (incl. Use-after-free), overflows (incl. Off-by-one) and double-free.
Linux Heap Exploitation Intro Series: Riding free on the heap – Double free attacks!
Intro Hello again and welcome to the third of our series. On today’s blog post we are going to see what is and how can we abuse a double free(). We are also going to take advantage of leaks that happen when doing double free()‘s and see some examples of code execution using said leaks – we are making our execution ride on frees!
As a last note, we are going to step things up a notch in this blog post and we are going to be using gdb as it will be crucial from now on. Sadly, ascii art doesn’t cut it anymore.
Linux Heap Exploitation Intro Series: The magicians cape – 1 Byte Overflow
Intro Hello again! It’s been a while since the last blog post. This is due to not having as much time as we wanted but hopefully you all kept the pace with this heapy things as they are easy to forget due to the heavy amount of little details the heap involves.
On this post we are going to demonstrate how a single byte overflow, with a user controlled value, can cause chunks to disappear for the implementation like a magician puts a cape on top of objects (chunks) and makes them disappear.
Linux Heap Exploitation Intro Series: Used and Abused – Use After Free
Intro After analysing the implementation of ptmalloc2 which, is a must read if you don’t know anything about the linux userland heap, I decided that for the second part of it, I would approach it as in a series of blog posts. Why? You might ask. Well it is easy for someone to tackle a problem in bite sized “chunks”. Understanding the heaps can be difficult and each of the techniques to be described in this series takes a decent amount of time to learn, understand and practice. Also, it is easier to find 15 minutes in a day rather than a few hours in a day. Also – hack the system.
Linux Heap Exploitation Intro Series – (BONUS) printf might be leaking!
Intro Hi there (again)! This series are going to an end as the next and feasible step is the widely known buffer overflow and its analysis in the heap and, I am not too convinced about it since the unsafe unlink method is long gone. But don’t be sad, today we are going for a bonus one! During the last post (double free attacks) one I stumbled across some weird behaviour that caught my attention by functions of the vfprintf.c family (for example printf or puts functions).
Painless intro to the Linux userland heap
-1 – Pre-Intro When looking at heap exploit tutorials most of the time I found myself lacking knowledge on the actual implementation and, soon, had the urge of knowing how it’s allocated and freed and why it’s done that way, memory wise.
-0.9 – ptmalloc2 The best source of knowledge with regards to the implementation of the heap is itself, the source code. Do not fear it, thankfully it is widely commented!
Page 1 of 1