Re: Debugging vs Reverse Engineering

[Guinevere Larsen <blarsen@redhat.com>]

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
>
>