Javier Jimenez

The hunt for Chromium issue 1072171

Intro The last few months I’ve been studying Chrome’s v8 internals and exploits with the focus of finding a type confusion bug. The good news is that I found one, so the fuzzing and analysis efforts didn’t go to waste. The bad news is that I can reliably trigger the vulnerability but I haven’t found a way to weaponise it yet. If you don’t have prior knowledge of v8, I encourage you to take some time and read through the previous post I wrote. It covers all of the basics regarding the v8 compiler and tools that helped me throughout my research. More importantly, it will help newcomers understand all of the research described within this post.

Being Stubborn Pays Off pt. 2 – Tale of two 0days on PRTG Network Monitor

Intro Last year I wrote how to weaponize CVE-2018-19204. This blog post will continue and elaborate on the finding and analysis of two additional vulnerabilities that were discovered during the process; one leading to an arbitrary write as system where the contents can’t be fully controlled and the other leading to Remote Code Execution as SYSTEM. Both vulnerabilities require you to have the administrator password for PRTG Network Monitor. Often you just get lucky, as the software defaults to prtgadmin:prtgadmin for the username and password respectively.

Intro to Chrome’s V8 from an exploit development angle

Intro Last Christmas I was doing quite a bit of research around an exploit for Chrome’s JavaScript engine, V8. While most of the concepts around the exploit might seem familiar: for example, what is known as a Type Confusion today has the almost exact concept (or outcome) as a Use-After-Free vulnerability, one of the differences is that there is no free/malloc exploited directly; there is a huge difference in the root cause of the exploitability of Type Confusion vulnerabilities. This is due to the optimisation phases that happen in the JavaScript engine before the Type Confusion bug is triggered. Because of this, after tackling an exploit and realising there’s so much about the internals that I needed to know, I tried getting my head around the tooling and the optimisation pipeline happening within V8, by reading the code and working on some examples while supporting myself on an amazing tool called Turbolizer by the v8 dev team.

Being Stubborn Pays Off pt. 1 – CVE-2018-19204

Intro During an internal assessment, I came across monitoring software that had default credentials configured. This monitoring software allowed for the creation of sensors, but, none of which would allow for code execution or any other things that could compromise an underlying system. Turns out, it was a vulnerable version based on a publicly known CVE, but there was no public exploit code. Join me in this quest on building an exploit!

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.

Fuzzing Apache httpd server with American Fuzzy Lop + persistent mode

Intro Recently, I reported CVE-2017-7668 (Apache Server buffer-over-read). This is a cross-post from my personal blog where I explain how to fuzz network programs with AFL by porting techniques learned in honggfuzz into AFL. After a small chat with Dominic he asked me to re-post it here which, for me it’s an honour to do so! The reported CVE was obtained with code analysis and instrumentation of the right parts of the code (mainly core and parsing) – First, with honggfuzz I got the initial dirty test cases and then, through radamsa generated a few thousands mutations and finally AFL with the technique described here.