Re: Debugging vs Reverse Engineering

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 <[email protected]> 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
>    <[email protected]> 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
>
>