Debugging vs Reverse Engineering

Debugging vs Reverse Engineering

[Jason Long via Gdb]

Hello folks,I have two questions:
1- Can a debugger like GDB be used to find the vulnerability?

2- When a hacker finds a vulnerability in a program, has that hacker used debugging techniques or reverse engineering?
Any idea welcomed.

Thank you.

Re: Debugging vs Reverse Engineering

[Guinevere Larsen via Gdb]

On 24/09/2023 15:09, Jason Long via Gdb wrote:
> Hello folks,I have two questions:
Hello, thanks for the questions!
> 1- Can a debugger like GDB be used to find the vulnerability?

Yes, you could use GDB to find some security vulnerabilities, though it 
is hardly the best tool for this job. The kind of stuff you'd find with 
GDB is a logic mistake that leads to information leaks or similar. In my 
experience, though, GDB is more useful to look at one unexpected 
behavior and figure out if that leads to a security vulnerability or 
not, rather than going form scratch and giving the program unexpected or 
malicious inputs.

>
> 2- When a hacker finds a vulnerability in a program, has that hacker used debugging techniques or reverse engineering?

Reverse engineering doesn't necessarily have to do with security. 
Reverse engineering is the act of getting something that is not 
understood and trying to understand it without having access to any kind 
of documentation. I don't recommend running unknown binaries in your 
machine, since GDB doesn't provide any security, but if you are doing 
that, stepping slowly and trying to understand how the program works, 
you are doing reverse engineering. It doesn't have to relate at all to 
security.

With that in mind, the answer to your question is "it depends". The 
stuff you can find with GDB alone will always involve debugging 
techinques, but with regards to reverse engineering techniques, the 
question is does the vulnerability come in from the fact that the 
attacker knows the internal mechanisms for the program or not? If it 
does, then yes you could say you found a vulnerability by reverse 
engineering.

> Any idea welcomed.
>
> Thank you.
>
I hope this helps!

-- 
Cheers,
Guinevere Larsen
She/Her/Hers

Re: Debugging vs Reverse Engineering

[Jason Long via Gdb]

Hi Larsen,Thank you so much for your reply.Your answer raised other questions in my mind.
What do you mean by "Giving the program unexpected or malicious inputs."? Do you mean Fuzzing?
Please take a look at these vulnerabilities:
https://www.cvedetails.com/cve/CVE-2022-31705/

https://www.cvedetails.com/cve/CVE-2023-32209/

What technique did the person who found these vulnerabilities use? Debugging or Reverse Engineering?


 
 
  On Sun, Sep 24, 2023 at 4:53 PM, Guinevere Larsen<blarsen@redhat.com> wrote:   On 24/09/2023 15:09, Jason Long via Gdb wrote:
> Hello folks,I have two questions:
Hello, thanks for the questions!
> 1- Can a debugger like GDB be used to find the vulnerability?

Yes, you could use GDB to find some security vulnerabilities, though it 
is hardly the best tool for this job. The kind of stuff you'd find with 
GDB is a logic mistake that leads to information leaks or similar. In my 
experience, though, GDB is more useful to look at one unexpected 
behavior and figure out if that leads to a security vulnerability or 
not, rather than going form scratch and giving the program unexpected or 
malicious inputs.

>
> 2- When a hacker finds a vulnerability in a program, has that hacker used debugging techniques or reverse engineering?

Reverse engineering doesn't necessarily have to do with security. 
Reverse engineering is the act of getting something that is not 
understood and trying to understand it without having access to any kind 
of documentation. I don't recommend running unknown binaries in your 
machine, since GDB doesn't provide any security, but if you are doing 
that, stepping slowly and trying to understand how the program works, 
you are doing reverse engineering. It doesn't have to relate at all to 
security.

With that in mind, the answer to your question is "it depends". The 
stuff you can find with GDB alone will always involve debugging 
techinques, but with regards to reverse engineering techniques, the 
question is does the vulnerability come in from the fact that the 
attacker knows the internal mechanisms for the program or not? If it 
does, then yes you could say you found a vulnerability by reverse 
engineering.

> Any idea welcomed.
>
> Thank you.
>
I hope this helps!

-- 
Cheers,
Guinevere Larsen
She/Her/Hers

  

Re: Debugging vs Reverse Engineering

[Guinevere Larsen via Gdb]

On 24/09/2023 20:12, Jason Long wrote:
>
> Hi Larsen,
You can call me Guinevere, or Gwen :)
> Thank you so much for your reply.
> Your answer raised other questions in my mind.
> What do you mean by "Giving the program unexpected or malicious 
> inputs."? Do you mean Fuzzing?

Fuzzing is one way to get a malicious input, but not the only one. For 
instance, look at the following example code:

char* get_name() {
     char* name;
     int name_size;
     printf("Please enter the length of your name:\n");
     scanf("%d", &name_size);
     /* Vulnerable code here:  */
     name = (char*) malloc (name_size * sizeof(char));
     printf("enter your name:\n");
     scanf("%s", name);
     return name;
}

int main() {
     printf("Hello %s", get_name());
}

For people used to looking for vulnerabilities, this has a very obvious 
issue in not verifying the size of input when reading a string, so you 
can just visually see that the input "1 AAAAAAAA" is enough to crash the 
program, so that would also be considered a malicious input. However, if 
you have a very big codebase, more complicated situations, or just 
aren't used to it, you might need a fuzzer to generate random inputs to 
see what makes your program crash.

The way you get to the answer is not important, the reason something is 
called a "malicious input" is if the person who designed it had 
malicious (evil) intent.

>
> Please take a look at these vulnerabilities:
> https://www.cvedetails.com/cve/CVE-2022-31705/
>
> https://www.cvedetails.com/cve/CVE-2023-32209/
>
> What technique did the person who found these vulnerabilities use? 
> Debugging or Reverse Engineering?

There isn't really a way to tell after the fact. I am reasonably sure 
the firefox one wasn't reverse engineering, since all the code is open 
source, so you don't need to reverse engineer it.

Quite likely both cases were just a fuzzer, and then some debugging was 
involved to understand exactly why the program crashed and if it was 
indeed a vulnerability or not, but there is no way to tell after the 
fact, and honestly if it was a real vulnerability, I don't think it 
really matters.

If you don't mind, why are you so interested in the distinction? I might 
be able to explain better in that case.

-- 
Cheers,
Guinevere Larsen
She/Her/Hers

>
>
>
>     On Sun, Sep 24, 2023 at 4:53 PM, Guinevere Larsen
>     <blarsen@redhat.com> wrote:
>     On 24/09/2023 15:09, Jason Long via Gdb wrote:
>     > Hello folks,I have two questions:
>     Hello, thanks for the questions!
>     > 1- Can a debugger like GDB be used to find the vulnerability?
>
>     Yes, you could use GDB to find some security vulnerabilities,
>     though it
>     is hardly the best tool for this job. The kind of stuff you'd find
>     with
>     GDB is a logic mistake that leads to information leaks or similar.
>     In my
>     experience, though, GDB is more useful to look at one unexpected
>     behavior and figure out if that leads to a security vulnerability or
>     not, rather than going form scratch and giving the program
>     unexpected or
>     malicious inputs.
>
>     >
>     > 2- When a hacker finds a vulnerability in a program, has that
>     hacker used debugging techniques or reverse engineering?
>
>     Reverse engineering doesn't necessarily have to do with security.
>     Reverse engineering is the act of getting something that is not
>     understood and trying to understand it without having access to
>     any kind
>     of documentation. I don't recommend running unknown binaries in your
>     machine, since GDB doesn't provide any security, but if you are doing
>     that, stepping slowly and trying to understand how the program works,
>     you are doing reverse engineering. It doesn't have to relate at
>     all to
>     security.
>
>     With that in mind, the answer to your question is "it depends". The
>     stuff you can find with GDB alone will always involve debugging
>     techinques, but with regards to reverse engineering techniques, the
>     question is does the vulnerability come in from the fact that the
>     attacker knows the internal mechanisms for the program or not? If it
>     does, then yes you could say you found a vulnerability by reverse
>
>     engineering.
>
>     > Any idea welcomed.
>     >
>     > Thank you.
>
>     >
>     I hope this helps!
>
>     -- 
>     Cheers,
>     Guinevere Larsen
>     She/Her/Hers
>
>

Re: Debugging vs Reverse Engineering

[Jason Long via Gdb]

Hi Gwen,
Thanks again.
 Can I send you a private email?



On Tuesday, September 26, 2023 at 05:03:51 PM GMT+3:30, Guinevere Larsen <blarsen@redhat.com> wrote: 

On 24/09/2023 20:12, Jason Long wrote:
>
> Hi Larsen,
You can call me Guinevere, or Gwen :)
> Thank you so much for your reply.
> Your answer raised other questions in my mind.
> What do you mean by "Giving the program unexpected or malicious 
> inputs."? Do you mean Fuzzing?

Fuzzing is one way to get a malicious input, but not the only one. For 
instance, look at the following example code:

char* get_name() {
    char* name;
    int name_size;
    printf("Please enter the length of your name:\n");
    scanf("%d", &name_size);
    /* Vulnerable code here:  */
    name = (char*) malloc (name_size * sizeof(char));
    printf("enter your name:\n");
    scanf("%s", name);
    return name;
}

int main() {
    printf("Hello %s", get_name());
}

For people used to looking for vulnerabilities, this has a very obvious 
issue in not verifying the size of input when reading a string, so you 
can just visually see that the input "1 AAAAAAAA" is enough to crash the 
program, so that would also be considered a malicious input. However, if 
you have a very big codebase, more complicated situations, or just 
aren't used to it, you might need a fuzzer to generate random inputs to 
see what makes your program crash.

The way you get to the answer is not important, the reason something is 
called a "malicious input" is if the person who designed it had 
malicious (evil) intent.

>
> Please take a look at these vulnerabilities:
> https://www.cvedetails.com/cve/CVE-2022-31705/
>
> https://www.cvedetails.com/cve/CVE-2023-32209/
>
> What technique did the person who found these vulnerabilities use? 
> Debugging or Reverse Engineering?

There isn't really a way to tell after the fact. I am reasonably sure 
the firefox one wasn't reverse engineering, since all the code is open 
source, so you don't need to reverse engineer it.

Quite likely both cases were just a fuzzer, and then some debugging was 
involved to understand exactly why the program crashed and if it was 
indeed a vulnerability or not, but there is no way to tell after the 
fact, and honestly if it was a real vulnerability, I don't think it 
really matters.

If you don't mind, why are you so interested in the distinction? I might 
be able to explain better in that case.

-- 
Cheers,
Guinevere Larsen
She/Her/Hers


>
>
>
>    On Sun, Sep 24, 2023 at 4:53 PM, Guinevere Larsen
>    <blarsen@redhat.com> wrote:
>    On 24/09/2023 15:09, Jason Long via Gdb wrote:
>    > Hello folks,I have two questions:
>    Hello, thanks for the questions!
>    > 1- Can a debugger like GDB be used to find the vulnerability?
>
>    Yes, you could use GDB to find some security vulnerabilities,
>    though it
>    is hardly the best tool for this job. The kind of stuff you'd find
>    with
>    GDB is a logic mistake that leads to information leaks or similar.
>    In my
>    experience, though, GDB is more useful to look at one unexpected
>    behavior and figure out if that leads to a security vulnerability or
>    not, rather than going form scratch and giving the program
>    unexpected or
>    malicious inputs.
>
>    >
>    > 2- When a hacker finds a vulnerability in a program, has that
>    hacker used debugging techniques or reverse engineering?
>
>    Reverse engineering doesn't necessarily have to do with security.
>    Reverse engineering is the act of getting something that is not
>    understood and trying to understand it without having access to
>    any kind
>    of documentation. I don't recommend running unknown binaries in your
>    machine, since GDB doesn't provide any security, but if you are doing
>    that, stepping slowly and trying to understand how the program works,
>    you are doing reverse engineering. It doesn't have to relate at
>    all to
>    security.
>
>    With that in mind, the answer to your question is "it depends". The
>    stuff you can find with GDB alone will always involve debugging
>    techinques, but with regards to reverse engineering techniques, the
>    question is does the vulnerability come in from the fact that the
>    attacker knows the internal mechanisms for the program or not? If it
>    does, then yes you could say you found a vulnerability by reverse
>
>    engineering.
>
>    > Any idea welcomed.
>    >
>    > Thank you.
>
>    >
>    I hope this helps!
>
>    -- 
>    Cheers,
>    Guinevere Larsen
>    She/Her/Hers
>
>

Re: Debugging vs Reverse Engineering

[Guinevere Larsen via Gdb]

On 27/09/2023 10:24, Jason Long wrote:
> Hi Gwen,
> Thanks again.
>   Can I send you a private email?
Sure, go ahead

-- 
Cheers,
Guinevere Larsen
She/Her/Hers

>
>
> On Tuesday, September 26, 2023 at 05:03:51 PM GMT+3:30, Guinevere Larsen <blarsen@redhat.com> wrote:
>
> On 24/09/2023 20:12, Jason Long wrote:
>> Hi Larsen,
> You can call me Guinevere, or Gwen :)
>> Thank you so much for your reply.
>> Your answer raised other questions in my mind.
>> What do you mean by "Giving the program unexpected or malicious
>> inputs."? Do you mean Fuzzing?
> Fuzzing is one way to get a malicious input, but not the only one. For
> instance, look at the following example code:
>
> char* get_name() {
>      char* name;
>      int name_size;
>      printf("Please enter the length of your name:\n");
>      scanf("%d", &name_size);
>      /* Vulnerable code here:  */
>      name = (char*) malloc (name_size * sizeof(char));
>      printf("enter your name:\n");
>      scanf("%s", name);
>      return name;
> }
>
> int main() {
>      printf("Hello %s", get_name());
> }
>
> For people used to looking for vulnerabilities, this has a very obvious
> issue in not verifying the size of input when reading a string, so you
> can just visually see that the input "1 AAAAAAAA" is enough to crash the
> program, so that would also be considered a malicious input. However, if
> you have a very big codebase, more complicated situations, or just
> aren't used to it, you might need a fuzzer to generate random inputs to
> see what makes your program crash.
>
> The way you get to the answer is not important, the reason something is
> called a "malicious input" is if the person who designed it had
> malicious (evil) intent.
>
>> Please take a look at these vulnerabilities:
>> https://www.cvedetails.com/cve/CVE-2022-31705/
>>
>> https://www.cvedetails.com/cve/CVE-2023-32209/
>>
>> What technique did the person who found these vulnerabilities use?
>> Debugging or Reverse Engineering?
> There isn't really a way to tell after the fact. I am reasonably sure
> the firefox one wasn't reverse engineering, since all the code is open
> source, so you don't need to reverse engineer it.
>
> Quite likely both cases were just a fuzzer, and then some debugging was
> involved to understand exactly why the program crashed and if it was
> indeed a vulnerability or not, but there is no way to tell after the
> fact, and honestly if it was a real vulnerability, I don't think it
> really matters.
>
> If you don't mind, why are you so interested in the distinction? I might
> be able to explain better in that case.
>