Is GDB just for bug hunting?

Is GDB just for bug hunting?

[Jason Long]

Hello,
I have some questions and I'm thankful if someone answer to them clearly:

1- I want to know, is GDB just useful for bug hunting or a security researcher can use it to find vulnerabilities too?

2- Is bug vs vulnerability? Consider someone that find an exploit in a program. He/she found a bug or Vulnerability? He/she used a debugger to find that or any special tool?

3- A debugger could be a Vulnerability researcher or vice versa?


Thank you.

Re: Is GDB just for bug hunting?

[Paul Koning]

I'll give some comments from the point of view of a user of gdb.

	paul

> On Apr 14, 2021, at 1:48 PM, Jason Long via Gdb <gdb@sourceware.org> wrote:
> 
> Hello,
> I have some questions and I'm thankful if someone answer to them clearly:
> 
> 1- I want to know, is GDB just useful for bug hunting or a security researcher can use it to find vulnerabilities too?
> 
> 2- Is bug vs vulnerability? Consider someone that find an exploit in a program. He/she found a bug or Vulnerability? He/she used a debugger to find that or any special tool?

A bug is any unintended behavior of a program, and more specifically an unintended behavior that has "bad" consequences.  So a vulnerability is a bug -- obviously by the first definition and almost certainly by the second as well.  But a lot of bugs are not vulnerabilities in the sense that the word is typically used.

I don't know what tools are specific to vulnerability search.  GDB does several things.  It lets you examine and modify a running process, and control the execution of a process (via breakpoints or stepping or the like) to find defects and especially to identify the exact cause of a previously observed defect.

It seems to me that finding a vulnerability (exploit) is more like discovering a bug (learnings of its existence) in the first place.  That's more likely to involve test tools or code reviews rather than GDB sessions.  Once a vulnerability (bug) has been recognized, the debugger can help understand the precise mechanism that caused it to exist, and suggest a solution.

I suppose another thing a GDB session could do is show sensitive data exposure; if a program handles sensitive data and allows that to exist in memory longer than strictly necessary, that's a risk and examining memory with GDB may be an easy way to spot such mistakes.  That would show potential risks like missing zeroization, though it would not necessarily tell you whether that's merely sloppy code or an actual weakness.

> 3- A debugger could be a Vulnerability researcher or vice versa?

I think mostly not.   While there's an overlap in tools and in what you look for, it seems to me the mindset of the two are rather different.  As an analogy, there's some overlap between cryptographers and programmers, but very few programmers are cryptographers.

	paul

Re: Is GDB just for bug hunting?

[Jason Long]

Thank you for your useful info.
If a program is close source, then code review canceled. Thus, how a security researcher finds a vulnerability in a program?






On Wednesday, April 14, 2021, 10:32:58 PM GMT+4:30, Paul Koning <paulkoning@comcast.net> wrote: 





I'll give some comments from the point of view of a user of gdb.

    paul

> On Apr 14, 2021, at 1:48 PM, Jason Long via Gdb <gdb@sourceware.org> wrote:
> 
> Hello,
> I have some questions and I'm thankful if someone answer to them clearly:
> 
> 1- I want to know, is GDB just useful for bug hunting or a security researcher can use it to find vulnerabilities too?
> 
> 2- Is bug vs vulnerability? Consider someone that find an exploit in a program. He/she found a bug or Vulnerability? He/she used a debugger to find that or any special tool?

A bug is any unintended behavior of a program, and more specifically an unintended behavior that has "bad" consequences.  So a vulnerability is a bug -- obviously by the first definition and almost certainly by the second as well.  But a lot of bugs are not vulnerabilities in the sense that the word is typically used.

I don't know what tools are specific to vulnerability search.  GDB does several things.  It lets you examine and modify a running process, and control the execution of a process (via breakpoints or stepping or the like) to find defects and especially to identify the exact cause of a previously observed defect.

It seems to me that finding a vulnerability (exploit) is more like discovering a bug (learnings of its existence) in the first place.  That's more likely to involve test tools or code reviews rather than GDB sessions.  Once a vulnerability (bug) has been recognized, the debugger can help understand the precise mechanism that caused it to exist, and suggest a solution.

I suppose another thing a GDB session could do is show sensitive data exposure; if a program handles sensitive data and allows that to exist in memory longer than strictly necessary, that's a risk and examining memory with GDB may be an easy way to spot such mistakes.  That would show potential risks like missing zeroization, though it would not necessarily tell you whether that's merely sloppy code or an actual weakness.


> 3- A debugger could be a Vulnerability researcher or vice versa?


I think mostly not.  While there's an overlap in tools and in what you look for, it seems to me the mindset of the two are rather different.  As an analogy, there's some overlap between cryptographers and programmers, but very few programmers are cryptographers.

    paul

Re: Is GDB just for bug hunting?

[Paul Koning]

> On Apr 14, 2021, at 2:37 PM, Jason Long <hack3rcon@yahoo.com> wrote:
> 
> Thank you for your useful info.
> If a program is close source, then code review canceled. Thus, how a security researcher finds a vulnerability in a program?

Agreed, code review only applies if the source is visible.  More precisely, if the source is allowed to be disclosed; researchers looking at the code while under NDA does not count and serves no significant purpose.

In those case, you're left with test stimuli and reverse engineering.  For "never seen before" defects, you either need luck (an existing test happens to catch it) or a different kind of luck (you created a new test that happens to catch it) or lots of skill (you saw the issue during a reverse engineering session).

GDB can help with reverse engineering.  It's probably not ideal for disassembly let alone decompiling, but it does offer disassembly and it also gives you insight into the state of the running application and how it changes during execution.

	paul

Re: Is GDB just for bug hunting?

[Joel Sherrill]

On Wed, Apr 14, 2021, 1:48 PM Paul Koning via Gdb <gdb@sourceware.org>
wrote:

>
>
> > On Apr 14, 2021, at 2:37 PM, Jason Long <hack3rcon@yahoo.com> wrote:
> >
> > Thank you for your useful info.
> > If a program is close source, then code review canceled. Thus, how a
> security researcher finds a vulnerability in a program?
>
> Agreed, code review only applies if the source is visible.  More
> precisely, if the source is allowed to be disclosed; researchers looking at
> the code while under NDA does not count and serves no significant purpose.
>
> In those case, you're left with test stimuli and reverse engineering.  For
> "never seen before" defects, you either need luck (an existing test happens
> to catch it) or a different kind of luck (you created a new test that
> happens to catch it) or lots of skill (you saw the issue during a reverse
> engineering session).
>
> GDB can help with reverse engineering.  It's probably not ideal for
> disassembly let alone decompiling, but it does offer disassembly and it
> also gives you insight into the state of the running application and how it
> changes during execution.
>

If you have source, you can use a trick I like. You can look at constant
data in a nice format even for cross compiled programs without attaching to
a target. Sometimes this is a good way to make sure your data structures
are right without really debugging.

I suppose with the Python scripting you could do a lot of you knew the
source. I've always wanted some scripting to analyse the state of an RTEMS
system via gdb to find priority inversions, etc. You could potentially do
some really powerful introspection.

But without application source, things become harder.

--joel



>         paul
>
>

Re: Is GDB just for bug hunting?

[Jason Long]

Thank you so much.
Thus, anybody that find a vulnerability in a software is a Reverse Engineer and not a Debugger. Am I right?
I searched in the Youtube.com and realized that someone use GDB for Reverse Engineering!!!
Can you introduce me a book about GDB or debugging that is OK for a beginner?





On Wednesday, April 14, 2021, 11:18:28 PM GMT+4:30, Paul Koning <paulkoning@comcast.net> wrote: 







> On Apr 14, 2021, at 2:37 PM, Jason Long <hack3rcon@yahoo.com> wrote:
> 
> Thank you for your useful info.
> If a program is close source, then code review canceled. Thus, how a security researcher finds a vulnerability in a program?

Agreed, code review only applies if the source is visible.  More precisely, if the source is allowed to be disclosed; researchers looking at the code while under NDA does not count and serves no significant purpose.

In those case, you're left with test stimuli and reverse engineering.  For "never seen before" defects, you either need luck (an existing test happens to catch it) or a different kind of luck (you created a new test that happens to catch it) or lots of skill (you saw the issue during a reverse engineering session).

GDB can help with reverse engineering.  It's probably not ideal for disassembly let alone decompiling, but it does offer disassembly and it also gives you insight into the state of the running application and how it changes during execution.


    paul