Linux - SecurityThis forum is for all security related questions.
Questions, tips, system compromises, firewalls, etc. are all included here.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
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.
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.
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?
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..
Last edited by linux4evr5581; 10-20-2016 at 03:53 PM.
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:
Quote:
Fuzz testing or fuzzing is a software testing technique, often automated or semi-automated, that involves providing invalid, unexpected, or random datato the inputs of a computer program.
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?
Maybe you should try writing some simple programs with buffer overflows and see how they work first.
Quote:
But can someone confirm for me whether you can spot a buffer overflow in a debugger in disassembly?
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).
@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.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.