Re: Debugging vs Reverse Engineering

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