How to find vulnerabilities in stripped binaries?
 

Do you just use tools like strace and a debugger to disassemble and find syscalls and then read the disassembly to find say for example a buffer overflow? Is that all you can do? I mean after all you don't have the source code.

If someone could shed some light on this particular topic I would be very grateful.

Thank you.

I'm curious what do you do if you find syscalls? Do you just not use those binaries, or contact the provider if you can?

I meant for example, finding a buffer overflow via memcpy.or someting similar.

That's kind of invalid. There are memcpy calls, how would you know if a memcpy overflows into the code segment if you do not know where the code and data segments are located? One can look at uninitialized memory and find instructions that are not instructions coded within. Similar to if you have code using a reference and they are using strcpy, you can't tell if they'll overflow because the library call was given a non-null terminated string versus was given a correctly formatted string.

Not sure that finding memcpy or memmove commands or similar will give you enough insight. That's also not necessarily a security vulnerability, just code with a bug in it. Correct?

Well, if you can tell by inserting strings of different lengths, you could find these calls in memcpy first, and verify.

I'm not following you.

You have a binary executable, it does what it does and you have no idea what code is intended to perform. Once again you could be looking at uninitialized data and technically find all or part of a valid command. You have no idea if a particular code path will absolutely be executed. In fact, some code may never be used, or rarely be used. Either case, the limits for the addresses, contents, and length of the copy are entirely unknown to you. For instance when copying a new update out from a file system, like updating firmware, let's say the firmware is 512K long. How would you know? How would you know the address it goes too? How would you know the address it comes from, especially since it's probably a pointer to a temporarily mounted file system? Further, in doing something like an upgrade, I might copy it to a scratch location to perform an MD5 or other checksum on it, or I might be receiving it from a network location, thus same thing I'd be storing it maybe to a RAM table or other location prior to storing it into a NV location. Either case, you have no idea what the addresses are, they are references, not hard coded addresses usually.

Sounds like you want to know how to do Fuzz testing.

https://en.wikipedia.org/wiki/Fuzz_testing

Any bug can be a security bug, Linus Torvalds explains in one of his speeches that there was a bug called "Zero Bug" which caused an overflow in Glipsy of a single byte on the stack, and the overflow was a 0 byte that turned into a root hole..

So, Im wrong then in thinking you can load a program in the debugger, and trigger memcpy calls, to see if they overflow?

Fuzzing is basically what I'm talking about. Am I on the right track with that or no?

I was under the mpression I could spot a stack buffer overflow in disassembly in a debugger. At least I thought so anyway.

From thei Wiki szboardstretcher provided:Therefore do note that this doesn't have to do with trying to reverse engineer a binary but instead testing the inputs of the program to all possible limits.

I looked at american fuzz lop, many of these programs seem like they have a steep learning curve. Any advice?

But can someone confirm for me whether you can spot a buffer overflow in a debugger in disassembly?

Maybe you should try writing some simple programs with buffer overflows and see how they work first.

There's no "stop on buffer overflow" functionality in a debugger. Buffer overflows sometimes trigger segfaults, which you can catch in a debugger (you can see those without a debugger too, since the program will terminate).

• You may be able to put a breakpoint in memcpy, but it may not trigger if the compiler inlined the call (and if it does trigger, it may also stop for calls that don't cause overflow).
• If you already know where in a program a buffer overflow will happen, you can put a breakpoint there (but it will also stop in normal runs when that code doesn't cause a buffer overflow).
• If you know which memory address the overflow will overwrite, you can put a watchpoint on it, and then the debugger will stop the program when the overflow happens (but it will also stop when the address written legitimately).

@ntubski Good points.

@rtmistler Could describe what you mean by uninitialized memory?

To elaborate further, I've read about virtual address space, and kernel address space. I've also read about Position-independent code. My other question is,

What is the difference between the memory referenced in objdump and the memory referenced in a debugger or even just at run-time?

Uninitialized memory is memory which doesn't have any particular data in it, was not specifically cleared, or set to a particular pattern. Thus the contents are usually random, or also remnants from other prior use.