From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id a1N7G+HdEmXCeR0AWB0awg (envelope-from ) for ; Tue, 26 Sep 2023 09:34:25 -0400 Authentication-Results: simark.ca; dkim=pass (1024-bit key; secure) header.d=sourceware.org header.i=@sourceware.org header.a=rsa-sha256 header.s=default header.b=sF/OJ+lx; dkim-atps=neutral Received: by simark.ca (Postfix, from userid 112) id 660651E0C3; Tue, 26 Sep 2023 09:34:25 -0400 (EDT) Received: from server2.sourceware.org (server2.sourceware.org [8.43.85.97]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (prime256v1) server-digest SHA256) (No client certificate requested) by simark.ca (Postfix) with ESMTPS id 571021E092 for ; Tue, 26 Sep 2023 09:34:23 -0400 (EDT) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id A1969385CC9D for ; Tue, 26 Sep 2023 13:34:22 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org A1969385CC9D DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sourceware.org; s=default; t=1695735262; bh=9EMGzZEGhNcv6VCKD5krdX2HJlVeL7ZvUXgPdB5VImc=; h=Date:Subject:To:References:In-Reply-To:List-Id:List-Unsubscribe: List-Archive:List-Post:List-Help:List-Subscribe:From:Reply-To: From; b=sF/OJ+lxI2NqM/+eCnpk0N9raUwR2XxevDpwzkuZt58bqTSQnWB4Kef5gBSrE//Vx O0OVOx920lUHwUUTyR+ruxAcj5lnGS2jH8UyB2GOyUfs+dZCAzfTnAElC3Rjj/B4Lr TbM7AYH0bH2gqL3XE98Ox7h9Ac6NBBqjQFt5E6CE= Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by sourceware.org (Postfix) with ESMTPS id C36FC3858C2A for ; Tue, 26 Sep 2023 13:33:51 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org C36FC3858C2A Received: from mail-ej1-f70.google.com (mail-ej1-f70.google.com [209.85.218.70]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-612-6N9pf4-DNpevxImHqgKzRA-1; Tue, 26 Sep 2023 09:33:50 -0400 X-MC-Unique: 6N9pf4-DNpevxImHqgKzRA-1 Received: by mail-ej1-f70.google.com with SMTP id a640c23a62f3a-9a9f282713fso716357466b.3 for ; Tue, 26 Sep 2023 06:33:49 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1695735229; x=1696340029; h=content-transfer-encoding:in-reply-to:from:references:to :content-language:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=9EMGzZEGhNcv6VCKD5krdX2HJlVeL7ZvUXgPdB5VImc=; b=Si4ey4cKj8Y5mucYCnCTBSf74u+zSVS5pr78xWCIN4VVIq0zpfefzTzFLhPsQA0ffY VdOudtBwOJ0mcXjv+/v8d/XAxzBn0HlNHvtRheKs1W+h4PWfaiea0f8qgpWtvUGbO7Nw t/Fbm+0qyKEzY19otzHHuh8MktQBgc49ytbLbTlP/8iiWGLo5oXTEOLIls2i8DHf6j4c iQv5PFS1jJ2/Bzy2Ci5HZb/9lwEw8uLydy4Kenpqd7V5S/TB4LWPni/TEF4bS18cLzRZ Saq8ET21Rqt6umkFlMf7cD6tbBvUe5YKFdnqVwWkGskpp7r0uqunkKac5tYuoe+zRyS5 QB2g== X-Gm-Message-State: AOJu0YwWry8nN8jN1pqT3aUrOruBB5MachWMqFSwizaGbu0kTjBGLqrI J8DctJX3+VI6ta7Q7kTTHWhTzfa7ccW1hhQwERBGnD3O+2eBtUjngHQVRsq8Fo3oX0Qdn4DGxBr 1IJEi5ESATFo= X-Received: by 2002:a17:906:109e:b0:9a9:e5bb:eddc with SMTP id u30-20020a170906109e00b009a9e5bbeddcmr8671217eju.16.1695735228917; Tue, 26 Sep 2023 06:33:48 -0700 (PDT) X-Google-Smtp-Source: AGHT+IE/E72JzQftMfN4DBy8+WRFpq2KwLmaw6kM6nmXaaCq/aAz03zWvF2fWDZM6gP8e4G9CC+f2Q== X-Received: by 2002:a17:906:109e:b0:9a9:e5bb:eddc with SMTP id u30-20020a170906109e00b009a9e5bbeddcmr8671199eju.16.1695735228506; Tue, 26 Sep 2023 06:33:48 -0700 (PDT) Received: from [192.168.0.129] (ip-94-112-227-180.bb.vodafone.cz. [94.112.227.180]) by smtp.gmail.com with ESMTPSA id i4-20020a170906850400b00992a8a54f32sm7775825ejx.139.2023.09.26.06.33.47 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 26 Sep 2023 06:33:48 -0700 (PDT) Message-ID: <53d9fdea-0180-bcaf-7cfb-e42f04d8bb10@redhat.com> Date: Tue, 26 Sep 2023 15:33:47 +0200 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.13.0 Subject: Re: Debugging vs Reverse Engineering To: Jason Long , SCOTT FIELDS via Gdb References: <2065504698.3252109.1695560949235.ref@mail.yahoo.com> <2065504698.3252109.1695560949235@mail.yahoo.com> <4e6bdb93-4671-9ee6-5a89-b9ffba797cff@redhat.com> <1700896107.3285250.1695579162353@mail.yahoo.com> In-Reply-To: <1700896107.3285250.1695579162353@mail.yahoo.com> X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Language: en-US Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-4.5 required=5.0 tests=BAYES_00, DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, NICE_REPLY_A, RCVD_IN_BARRACUDACENTRAL, RCVD_IN_DNSWL_NONE, RCVD_IN_MSPIKE_H3, RCVD_IN_MSPIKE_WL, SPF_HELO_NONE, SPF_NONE, TXREP autolearn=no autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org X-BeenThere: gdb@sourceware.org X-Mailman-Version: 2.1.30 Precedence: list List-Id: Gdb mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , From: Guinevere Larsen via Gdb Reply-To: Guinevere Larsen Errors-To: gdb-bounces+public-inbox=simark.ca@sourceware.org Sender: "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 > 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 > >