public inbox for gdb@sourceware.org
 help / color / mirror / Atom feed
From: Jason Long <hack3rcon@yahoo.com>
To: SCOTT FIELDS via Gdb <gdb@sourceware.org>,
	 Guinevere Larsen <blarsen@redhat.com>
Subject: Re: Debugging vs Reverse Engineering
Date: Wed, 27 Sep 2023 08:24:39 +0000 (UTC)	[thread overview]
Message-ID: <1833873555.2376848.1695803079542@mail.yahoo.com> (raw)
In-Reply-To: <53d9fdea-0180-bcaf-7cfb-e42f04d8bb10@redhat.com>

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


  reply	other threads:[~2023-09-27  8:24 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <2065504698.3252109.1695560949235.ref@mail.yahoo.com>
2023-09-24 13:09 ` Jason Long
2023-09-24 13:23   ` Guinevere Larsen
2023-09-24 18:12     ` Jason Long
2023-09-26 13:33       ` Guinevere Larsen
2023-09-27  8:24         ` Jason Long [this message]
2023-09-27  8:31           ` Guinevere Larsen

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1833873555.2376848.1695803079542@mail.yahoo.com \
    --to=hack3rcon@yahoo.com \
    --cc=blarsen@redhat.com \
    --cc=gdb@sourceware.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).