前几天 ZBR 发了这个 repo，我寻思没听过，看着攻击能力还挺强的，于是浅浅分析一下。

简单来说，这个 house 能做这样一件事：在没有泄露的情况下绕过 ASLR 实现代码执行。

而它的利用条件如下：

• Partial RELRO / No RELRO —— 它需要修改 .dynsym 去修改 dlresolve 结果
• 可以分配较大的堆 —— 要使其由 MMAP 分配
• 能够改写这个堆的 prev_size 和 size 字段，使得 IS_MMAPED 位被改写

本文将基于 2.31 的环境，复现 Docker 可以使用下面的 Dockerfile：

FROM ubuntu:20.04

ENV DEBIAN_FRONTEND noninteractive

# Update
RUN apt-get update -y && apt-get install socat -y gdb vim tmux python3 python3-pip 

# General things needed for pwntools and pwndbg to run
RUN apt-get install git build-essential libssl-dev libffi-dev libxml2-dev libxslt1-dev zlib1g-dev patchelf python3-dev -y 

RUN pip3 install pwn

# Install pwndbg
RUN git clone https://github.com/pwndbg/pwndbg && cd pwndbg && ./setup.sh && cd ../ 

RUN echo "set auto-load safe-path /" >> /root/.gdbinit

# Challenge files to ADD
RUN git clone https://github.com/mdulin2/house-of-muney 

# Fixes the loader and recompiles the binary for us :) 
RUN cd house-of-muney && ./compile.sh

不知道为什么以前都不把这些记录下来，然后每次做到的时候都会忘了从零开始学。

本文将主要介绍 2.23 和 2.31 版本下的利用，2.27 和 2.23 差不多，多填一个 tcache 即可。2.29 和 2.31 也差不多，多了一个 key。

因此，阅读本文你需要对 Heap 的分配有一定的基础，本文将更多涉及方法而非原理。

本文涉及的挑战主要有以下几个特征

• 存在 off-by-null
• 分配次数几乎不受限
• 分配大小几乎不受限或是能分配 largebin 范围
• 不存在 edit 函数或只能 edit 一次
• 只能 show 一次（按理来说不能 show 也可以，但是堆块分配太麻烦了，做这种题不如睡觉）

Attachment download link: https://pwnable.tw/static/chall/netatalk.tgz + https://pwnable.tw/static/libc/libc-18292bd12d37bfaf58e8dded9db7f1f5da1192cb.so

It took about 1.5 days, and overall it was a very productive debugging and reproducing process. I learned some exploitation and debugging techniques, and it was very helpful for expanding my mindset.

The discovery process of the vulnerability is explained clearly by the author in Exploiting an 18 Year Old Bug. A Write-up for CVE-2018–1160 | by Jacob Baines, which is very interesting. You can also find a translated version at Discovery and Exploitation of Netatalk CVE-2018-1160_c01dkit's Blog-CSDN Blog.

The author mentioned in their blog that this vulnerability can only be exploited on NAS with -no-pie. However, the creator of the HITCON 2019 challenge, DDAA, provided an exploit approach in HITCON CTF 2019 Pwn 371 Netatalk (ddaa.tw), which basically involves leveraging the nature of fork where child processes do not change the memory layout — in other words, ASLR plays a very minor role (laughs). This way, we can expose a valid address through a side channel and then exploit it.

Recently encountered this vulnerability, it seems to have a wide range of potential exploits. Although most machines in China seem to have a relatively low version of libc, let's take a look at it first.

Environment Setup​

Testing Environment​

OS: Ubuntu 22.04.1 LTS on Windows 10 x86_64

Kernel: 5.15.123.1-microsoft-standard-WSL2

Glibc: 2.35-0ubuntu3.3

Attachment to the topic: http://121.40.89.206/20230311/kheap_9010ffcba2dfbfd58c7ab541015b24ec.zip

Although I've studied the kernel a bit, this is the first attempt at a kernel PWN challenge.

Take a look at House_of_spirit, which is a technique that relies on constructing fake_chunk on the stack to achieve (almost) arbitrary write. It depends on fastbin.

After dawdling for so long, I finally managed to dive into the world of HEAP.

Thanks to Ayang's (bushi) guidance.

Let's first take a look at the simplest Use After Free exploit, which requires minimal understanding of heap concepts. I will probably write about Double Free + Unlink tomorrow.

I used the original challenge hacknote from CTF-WIKI.

Recently, when I set up Ubuntu18 and was testing it, I encountered a problem.

After researching for a long time, I finally solved it and decided to take some notes.

Challenge -- Buuoj -- RIP

Double Free is an easily exploitable vulnerability in the Fastbin, let's examine it.

The overall principle is quite simple, as explained on ctf-wiki. The main idea is that due to the way the fastbin checks are implemented, it only checks the head of the linked list and does not clear prev_in_use when freeing a chunk.

There is relevant source code available in the link provided as well.

Ready to study the bypass under different protection mechanisms before diving into the heap.

Let's take a look at Canary today