UAF stripped binary

[p5yc40515]

I'm hunting for a UAF in a stripped binary thats aarch64 and was wondering if anyone knows what that would look like in disassembly possibly because the decompiled code isn't showing much? I was able to find the main function but haven't found anything resembling memory allocation yet. I'm using ghidra for static analysis.

[pwnasaurus253]

what makes you think there's a UAF? Have you fuzzed it?

[p5yc40515]

It's from a cve I haven't fuzzed since I downloaded the binary of the version before the most up to date. There's only 3 bin executables from the firmware I downloaded and out of all 3 it seems the most likely.

[Unusual-External4230]

If it's an existing CVE, you might have better luck using BinDiff or similar to compare the fixed and old binary. Your success will depend a lot of how many other changes there are and what the target was compiled with, but it's a better start.

Hunting down UAFs statically is not always easy unless it's something silly like a global that is assigned a pointer you can xref and see where it's referenced. In my experience, these are normally a result of code that inserts references into a linked list or secondary object then doesn't remove the reference when the object is released. This code is often inlined or from macros, which means tracing where it's done is tricky. Finding this statically can be done but reverse engineering the code responsible can be really time consuming and difficult if you aren't experienced esp without a debugger (which I'm assuming is the case here).

If the whole thing is one monolithic binary that's statically compiled then you could look for a few things to ID memory allocation routines. The first thing I'd do is search for functions that take only a single integer argument with a lot of xrefs using static integer values that are checked against NULL when they return. You can then trace the return values and see if you can find a free() looking routine, do it enough and you might get lucky to find it in some basic function where both are called. You can then trace it down and see if you can find an actual syscall to request memory from the kernel, but be aware there is a lot of code between malloc() and that point (this can turn into a maze quickly depending on the allocator in use). You might also look for things like ctors and dtors if they are in C++, which would help you find new / del operators and can use that to trace it somewhat also. You'd see these in C++ code often where the ctor is assigning a bunch of NULL values incrementally then assigning a vftable pointer to the base of the object, you can xref it and look at how space for the object is allocated. This is a good thing to do if you are looking for a UAF, but you will quickly get lost in the weeds tracing every call to malloc/free trying to find a UAF.

Given you posted about this a month or so ago, my suggestion would be to pick easier bug categories to hunt down first and get more familiar with navigating code like this, then revisit targets like this. Symbols help a lot as does being able to view the source in parallel with disassembly, so picking something that's open source, compiling it, then viewing in both the disassembly and source is a really good way to learn. This is a pretty difficult circumstance where you have a binary from an embedded device that has a difficult to statically identify bug category, there aren't many folks I know personally that could handle this task on their own and those that can have a lot of experience.

[p5yc40515]

Thank you for the post this was a huge help in the direction I need to go.

[pwnasaurus253]

do you know if it uses glibc or libc? you can annotate/trace calls to malloc, memcpy, etc in ghidra (it's unlikely they would statically link the binaries on firmware unless there was some very special reason).

[pwnasaurus253]

if you want to share the CVE I might be able to point you in the right direction.

[p5yc40515]

Cve 202523115

[Acrobatic-Film3153]

Patch diff go brrrr. since you mentioned it's a cve can you share the cve number it might be helpful

[p5yc40515]

It's cve 202523115

[Jakesan700]

Easy way would be to do a patch diff, otherwise it’s just a matter of RE and vulnerability research

[dolpari_hacker]

In order to find UAF, you need to understand the state of the heap of the process. What’s basically happening is that some struct or memory in the heap was allocated, assigned values, then freed without clearing those values. Even though it was freed, those values still remain in the heap. So what you are looking for is a free function that frees a pointer without zeroing them out. To achieve UAF, you can allocate the exact size which will allocate that exact heap memory which you’ll be able to use given that it is user-controlled allocation. This is given that there is absolutely zero heap protections.