Introduction

Have you ever discovered something amazing only to later realize that somebody else had already beaten you to it? In this article, I wanted to describe a new (rediscovered) GLibC heap exploitation method that works on all versions of the allocator. With this method, an attacker can write a heap value to an arbitrary location (WRITE-WHERE primitive).

When I started looking for new ways to exploit the allocator via the non-main arena chunks, I thought I had found a new technique! However, part way through writing this article, I reread the original post (Malloc Malefaricum) on the House of Mind only to realize that there is a fastbin variant of the attack as well. The original use case for the fastbin variant of the House of Mind writes a heap pointer to a GOT address to jump to shellcode. But, this technique to trivially pop a shell is no longer viable because of NX. With the original House of Mind being patched and the fastbin variant no longer being an auto shell, this technique was mostly forgotten about, waiting to be rediscovered for a new purpose. So, new or not, nobody seems to be talking about this technique. In this article I wanted to shed light onto the House of Mind's Fastbin Variant as a useful WRITE-WHERE primitive and discuss when it can be used.

This post will (hopefully) have a POC in how2heap; the link is currently to a pull request with all of the code. For more security related content, check out this blog for other things, such as the House of Muney heap exploitation technique.

Before we get to the meat of the technique, we will go over how the heap allocator works. I cannot stress enough how important understanding the allocator is for heap exploitation. Trying to pwn the heap without understanding the inner workings of the allocator is like trying to shot a fish in a lake.

Chunks

Chunks are the main object that users interact with. There are two main states to a chunk: allocated and free. The following picture demonstrates a free chunk:

The first field is the size of the previous chunk (prev_size). This is only used if the previous chunk is free. The second field is the chunk size. The chunk size represents the size of the data of the chunk and the metadata about the chunk. The metadata of the chunk includes three fields: prev_inuse (if the previous chunk is in use), mmap (is the chunk mmapped) and if the chunk is in a non-main arena. We will touch on the non-main arena bit more in depth later.

On an allocated (non-free) chunk, the third and fourth field are used as data sections. However, on a free chunk, the third field is used in order to store a pointer to other freed chunks. This field is known as the forward pointer or the Fd field. The fourth field is exactly the same, except that it stores a backwards pointer or bk.

Introduction

Exploiting different heap libraries tends to be difficult, complex and requires a deep knowledge of the library itself. Recently, Qualys decided to go back and exploit a 15 year bug in QMail that was thought to unexploitable with some incredible techniques. This exploit uses a very interesting quirk of Malloc and exploit method that had not been seen before, which I have decided to name the House of Muney.

In this article, I wanted to shed more light on the exploitation method that was used by the Qualys researchers to ensure there is a well-documented location for this exploit method. In short, it is broken up into Munmaping part of LibC and to rewrite the symbol table to get code execution. There are two main perks of this technique: this bypasses ASLR entirely and works on mmap chunks in GLibC Malloc.

Just as a fair warning, this article has quite a bit of background knowledge to understand the exploit. If you think you have a good understanding a section, it is recommended you still review the section just to refamilarize yourself with the content. In this article, the following is discussed as background:

• Malloc Chunk (general)
• Mmap and Munmap
• Malloc Mmap Chunks
• ELF Symbol Resolution

The article also comes with a working POC on version 2.31 of Malloc on my Github (mdulin2) at House of Muney if you would like to follow along. Additionally, if you want more security content, take a look at the resources or other blog posts. Now, with the introduction out of the way, let's dive into the technical details.

GLibC Malloc Background

Chunks

Chunks are the main object that users interact with. There are two main states to a chunk: allocated and free. The following picture demonstrates a free chunk:

The first field is the size of the previous chunk (prev_size). This is only used if the previous chunk is free. The second field is the chunk size. The chunk size represents the size of the data of the chunk and the metadata about the chunk. The metadata of the chunk includes three fields: prev_inuse (if the previous chunk is in use), mmap (is the chunk mmapped) and if the chunk is in a non-main arena.

On an allocated (non-free) chunk, the third and fourth field are used as data sections. However, on a free chunk, the third field is used in order to store a pointer to other freed chunks. This field is known as the forward pointer or the Fd field. The fourth field is exactly the same, except that it stores a backwards pointer or bk.

Introduction

Recently, a friend of mine (from outside the United States) had a third party make them a website for eCommerce sales and blogging. Because of this, they wanted me to do a quick review of the security of the application. After reviewing the account handling on the application I determined that the Password Reset functionality was the worst implementation ever made. If you can think of an issue I bet this had it... Below, we will be going into what went wrong and how to find these types of issues yourself.

Back to the Basics

If accounts exists on a website there are some basic features of it:

• Create Account
• Login
• Forgot Password/ Password Reset
• Update Account
• Delete Account
• View Account

If any of these is done in insecure way, major havoc can occur. In this blog post, we will be paying special attention to the Password Reset functionality of a website and how it can go wrong.

Basic Flow of Password Reset

What do you do if a user forgets their password? Well, you want them to be able to login, but you still want to make sure that it is the correct user. So, it is time to rest their password.

Generally, a users account is tied to an email. With this, the website can send this users email a magic link. This magic link deems that the user is trusted and will allow them to change the password.

This research was done by myself a while back and just got posted on my companies blog. Even though I generally post pwn or lower level articles on this blog, I am also into web application security and dive into the other things in my free time.

This research article is about securely routing requests in different web frameworks, such as Django, Flask, Ruby on Rails and more. The major consequence of insecurely routing pages is a CSRF bypass, as only particular HTTP methods are protected by CSRF. Overall, the research turned up some interesting results! So, I highly recommend taking a read in order to learn how to securely route requests in the most popular backend web frameworks.

The link for the article can be found on Security Innovation's website. Or, click here for the full article.

Introduction

On May 21st 2020, Checkpoint Research released a post that detailed the results of a security patch to multiple variations of Malloc, including the Malloc used in GLibC. This patch attempts to fix the inherit insecurities within singly linked lists being used as a bin data structure. In this article, I will be diving into how the security patches work and what this actually means for binary exploitation. For this specific article, we will dive into the patches put into GLibC's Malloc. However, the concepts of the mitigations will directly apply to all other versions of Malloc (just not the specific implementation details).

GLibC Malloc

In order to understand the rest of the article, a primer on the data structures used within GLibC's Malloc is required. For the purpose of this article there are two main data structures: chunks and bins.

Chunks

Chunks are the main object that users interact with. There are two main states to a chunk: allocated and free. The following picture demonstrates a free chunk:

The first field is the size of the previous chunk (prev_size). This is only used if the previous chunk is free. The second field is the chunk size. The chunk size represents the size of the data of the chunk and the metadata about the chunk (the first 3 bits of the size).

On a free chunk, the third field is used in order to store a pointer to other freed chunks. This field is known as the forward pointer or the Fd field. The fourth field is exactly the same, except that it stores a backwards pointer or bk.