LinuxQuestions.org
Help answer threads with 0 replies.
Go Back   LinuxQuestions.org > Forums > Linux Forums > Linux - Security
User Name
Password
Linux - Security This forum is for all security related questions.
Questions, tips, system compromises, firewalls, etc. are all included here.

Notices


Reply
  Search this Thread
Old 10-20-2016, 12:23 PM   #1
watchintv
Member
 
Registered: Oct 2016
Posts: 57

Rep: Reputation: Disabled
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.
 
Old 10-20-2016, 01:02 PM   #2
rtmistler
Moderator
 
Registered: Mar 2011
Location: USA
Distribution: MINT Debian, Angstrom, SUSE, Ubuntu, Debian
Posts: 9,877
Blog Entries: 13

Rep: Reputation: 4930Reputation: 4930Reputation: 4930Reputation: 4930Reputation: 4930Reputation: 4930Reputation: 4930Reputation: 4930Reputation: 4930Reputation: 4930Reputation: 4930
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?
 
Old 10-20-2016, 01:15 PM   #3
watchintv
Member
 
Registered: Oct 2016
Posts: 57

Original Poster
Rep: Reputation: Disabled
I meant for example, finding a buffer overflow via memcpy.or someting similar.
 
Old 10-20-2016, 01:20 PM   #4
rtmistler
Moderator
 
Registered: Mar 2011
Location: USA
Distribution: MINT Debian, Angstrom, SUSE, Ubuntu, Debian
Posts: 9,877
Blog Entries: 13

Rep: Reputation: 4930Reputation: 4930Reputation: 4930Reputation: 4930Reputation: 4930Reputation: 4930Reputation: 4930Reputation: 4930Reputation: 4930Reputation: 4930Reputation: 4930
Quote:
Originally Posted by watchintv View Post
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?
 
Old 10-20-2016, 01:27 PM   #5
watchintv
Member
 
Registered: Oct 2016
Posts: 57

Original Poster
Rep: Reputation: Disabled
Well, if you can tell by inserting strings of different lengths, you could find these calls in memcpy first, and verify.
 
Old 10-20-2016, 01:44 PM   #6
rtmistler
Moderator
 
Registered: Mar 2011
Location: USA
Distribution: MINT Debian, Angstrom, SUSE, Ubuntu, Debian
Posts: 9,877
Blog Entries: 13

Rep: Reputation: 4930Reputation: 4930Reputation: 4930Reputation: 4930Reputation: 4930Reputation: 4930Reputation: 4930Reputation: 4930Reputation: 4930Reputation: 4930Reputation: 4930
Quote:
Originally Posted by watchintv View Post
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.
 
Old 10-20-2016, 01:46 PM   #7
szboardstretcher
Senior Member
 
Registered: Aug 2006
Location: Detroit, MI
Distribution: GNU/Linux systemd
Posts: 4,278

Rep: Reputation: 1694Reputation: 1694Reputation: 1694Reputation: 1694Reputation: 1694Reputation: 1694Reputation: 1694Reputation: 1694Reputation: 1694Reputation: 1694Reputation: 1694
Sounds like you want to know how to do Fuzz testing.

https://en.wikipedia.org/wiki/Fuzz_testing
 
Old 10-20-2016, 03:49 PM   #8
linux4evr5581
Member
 
Registered: Sep 2016
Location: USA
Posts: 275

Rep: Reputation: Disabled
Quote:
Originally Posted by rtmistler View Post
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.
 
Old 10-20-2016, 11:39 PM   #9
watchintv
Member
 
Registered: Oct 2016
Posts: 57

Original Poster
Rep: Reputation: Disabled
So, Im wrong then in thinking you can load a program in the debugger, and trigger memcpy calls, to see if they overflow?
 
Old 10-21-2016, 06:01 AM   #10
watchintv
Member
 
Registered: Oct 2016
Posts: 57

Original Poster
Rep: Reputation: Disabled
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.

Last edited by watchintv; 10-21-2016 at 06:03 AM.
 
Old 10-21-2016, 12:27 PM   #11
rtmistler
Moderator
 
Registered: Mar 2011
Location: USA
Distribution: MINT Debian, Angstrom, SUSE, Ubuntu, Debian
Posts: 9,877
Blog Entries: 13

Rep: Reputation: 4930Reputation: 4930Reputation: 4930Reputation: 4930Reputation: 4930Reputation: 4930Reputation: 4930Reputation: 4930Reputation: 4930Reputation: 4930Reputation: 4930
Quote:
Originally Posted by szboardstretcher View Post
Sounds like you want to know how to do Fuzz testing.

https://en.wikipedia.org/wiki/Fuzz_testing
Quote:
Originally Posted by watchintv View Post
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 data to 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.
 
Old 10-21-2016, 01:13 PM   #12
watchintv
Member
 
Registered: Oct 2016
Posts: 57

Original Poster
Rep: Reputation: Disabled
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?
 
Old 10-21-2016, 05:02 PM   #13
ntubski
Senior Member
 
Registered: Nov 2005
Distribution: Debian, Arch
Posts: 3,774

Rep: Reputation: 2081Reputation: 2081Reputation: 2081Reputation: 2081Reputation: 2081Reputation: 2081Reputation: 2081Reputation: 2081Reputation: 2081Reputation: 2081Reputation: 2081
Quote:
Originally Posted by watchintv View Post
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).
 
Old 10-28-2016, 11:49 PM   #14
watchintv
Member
 
Registered: Oct 2016
Posts: 57

Original Poster
Rep: Reputation: Disabled
@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?
 
Old 10-29-2016, 12:14 AM   #15
rtmistler
Moderator
 
Registered: Mar 2011
Location: USA
Distribution: MINT Debian, Angstrom, SUSE, Ubuntu, Debian
Posts: 9,877
Blog Entries: 13

Rep: Reputation: 4930Reputation: 4930Reputation: 4930Reputation: 4930Reputation: 4930Reputation: 4930Reputation: 4930Reputation: 4930Reputation: 4930Reputation: 4930Reputation: 4930
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.
 
  


Reply


Thread Tools Search this Thread
Search this Thread:

Advanced Search

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is Off
HTML code is Off



Similar Threads
Thread Thread Starter Forum Replies Last Post
LXer: Google “Project Zero” hopes to find zero-day vulnerabilities before the NSA LXer Syndicated Linux News 0 07-16-2014 01:21 PM
Where can I find the debian /bin/ binaries? J_Sherman Debian 3 06-20-2009 07:04 AM
Can't find 2 binaries!!!!! jong357 Slackware 2 03-12-2005 06:27 PM
stripped/non-stripped binaries spuzzzzzzz Linux - General 4 02-13-2004 06:11 AM
Stripped||not stripped Cyth Linux - General 4 11-20-2001 01:47 PM

LinuxQuestions.org > Forums > Linux Forums > Linux - Security

All times are GMT -5. The time now is 02:18 AM.

Main Menu
Advertisement
My LQ
Write for LQ
LinuxQuestions.org is looking for people interested in writing Editorials, Articles, Reviews, and more. If you'd like to contribute content, let us know.
Main Menu
Syndicate
RSS1  Latest Threads
RSS1  LQ News
Twitter: @linuxquestions
Open Source Consulting | Domain Registration