public inbox for gdb@sourceware.org
 help / color / mirror / Atom feed
From: Paul Koning <paulkoning@comcast.net>
To: Siddhesh Poyarekar <siddhesh@gotplt.org>
Cc: Richard Earnshaw <Richard.Earnshaw@foss.arm.com>,
	Nick Clifton <nickc@redhat.com>,
	Binutils <binutils@sourceware.org>,
	"gdb@sourceware.org" <gdb@sourceware.org>
Subject: Re: RFC: Adding a SECURITY.md document to the Binutils
Date: Thu, 13 Apr 2023 13:37:59 -0400	[thread overview]
Message-ID: <2FDDD795-B713-41B8-A650-1CA06F027416@comcast.net> (raw)
In-Reply-To: <efcde430-a38c-659a-b448-9599da00aee2@gotplt.org>



> On Apr 13, 2023, at 1:29 PM, Siddhesh Poyarekar <siddhesh@gotplt.org> wrote:
> 
> On 2023-04-13 13:05, Paul Koning wrote:
>>> On Apr 13, 2023, at 1:00 PM, Siddhesh Poyarekar <siddhesh@gotplt.org> wrote:
>>> 
>>> On 2023-04-13 12:49, Paul Koning wrote:
>>>> If someone sends me an executable file, and I execute it and suffer a virus, shame on me.  If someone sends me a C source file and I compile and link that BUT DO NOT EXECUTE the resulting executable, and I suffer a virus, shame on the tool.
>>> 
>>> If someone sends me a C source file and I compile and link it without inspecting it first, then definitely shame on me again.  Compilers and linkers assume *trusted* input.
>> That's news to me.
>> It is true that not all text is valid C, and some text has "undefined" behavior.  But "undefined" is a property of the resulting executable program, NOT of the act of compiling it.  I have never before seen anyone suggest that submitting a bad program to a compiler could reasonably be expected to result in that compiler attacking the security of your system, or that if it did so it wouldn't be a security bug in that compiler.
> 
> I haven't seen anyone suggest (and have seen many balk at) the idea of crashes/buffer overruns in compilers being considered security issues. 

Not all buffer overruns cause security issues.  Those that crash the program with the buffer overrun are not security issues (unless you're considering the category of Denial of Service attacks).  But a buffer overrun that enables the execution of arbitrary code IS a security issue.

Who do you know to "balk at" that principle?

This is no different from how one analyzes buffer overruns in networking applications.  If the consequence of the error is nothing worse than an abort of that application, it's DoS and would typically not be considered serious.  If it allows code to be inserted and executed in the context of the application, then that is serious and is a security defect.  The same goes for any other application whose specification says that it processes -- but does not execute -- its inputs.

	paul



  reply	other threads:[~2023-04-13 17:38 UTC|newest]

Thread overview: 56+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-04-07  8:42 Nick Clifton
2023-04-07 10:36 ` Eli Zaretskii
2023-04-11 13:29   ` Nick Clifton
2023-04-11 14:23     ` Simon Marchi
2023-04-11 15:00       ` Eli Zaretskii
2023-04-11 16:22         ` Nick Clifton
2023-04-11 16:32           ` Matt Rice
2023-04-11 18:18         ` J.W. Jagersma
2023-04-12  8:43           ` Nick Clifton
2023-04-08  6:30 ` Jan Beulich
2023-04-10 18:30 ` John Baldwin
2023-04-20 15:56   ` Nick Clifton
2023-04-11 19:45 ` Ian Lance Taylor
2023-04-12 16:02 ` Richard Earnshaw
2023-04-12 16:26   ` Siddhesh Poyarekar
2023-04-12 16:52     ` Richard Earnshaw
2023-04-12 16:58       ` Paul Koning
2023-04-12 17:10       ` Siddhesh Poyarekar
2023-04-13  3:51         ` Alan Modra
2023-04-13  4:25           ` Siddhesh Poyarekar
2023-04-13  5:16             ` Alan Modra
2023-04-13 12:00               ` Siddhesh Poyarekar
2023-04-13 10:25         ` Richard Earnshaw
2023-04-13 11:53           ` Siddhesh Poyarekar
2023-04-13 12:37             ` Richard Earnshaw
2023-04-13 12:54               ` Siddhesh Poyarekar
2023-04-13 13:11                 ` Richard Earnshaw
2023-04-13 13:35                   ` Siddhesh Poyarekar
2023-04-13 13:40                     ` Richard Earnshaw
2023-04-13 13:56                       ` Siddhesh Poyarekar
2023-04-13 14:50                         ` Richard Earnshaw
2023-04-13 15:02                           ` Siddhesh Poyarekar
2023-04-13 15:05                             ` Richard Earnshaw
2023-04-13 16:42                               ` Siddhesh Poyarekar
2023-04-14  9:52                                 ` Richard Earnshaw
2023-04-14 12:43                                   ` Siddhesh Poyarekar
2023-04-14 12:49                                     ` Richard Earnshaw
2023-04-14 13:13                                       ` Siddhesh Poyarekar
2023-04-13 15:08                             ` Paul Koning
2023-04-13 16:02                               ` Siddhesh Poyarekar
2023-04-13 16:49                                 ` Paul Koning
2023-04-13 17:00                                   ` Siddhesh Poyarekar
2023-04-13 17:05                                     ` Paul Koning
2023-04-13 17:29                                       ` Siddhesh Poyarekar
2023-04-13 17:37                                         ` Paul Koning [this message]
2023-04-13 18:16                                           ` Siddhesh Poyarekar
2023-04-14 17:37                                     ` Ian Lance Taylor
2023-04-14 18:27                                       ` Siddhesh Poyarekar
2023-04-14 20:46                                         ` Ian Lance Taylor
2023-04-14 21:24                                           ` Siddhesh Poyarekar
2023-04-17 15:31                                           ` Michael Matz
2023-04-17 19:55                                             ` Ian Lance Taylor
2023-04-14 19:45                                       ` DJ Delorie
2023-04-14 20:49                                         ` Ian Lance Taylor
2023-04-15  6:41                                           ` Xi Ruoyao
2023-04-13 16:06                               ` Richard Earnshaw

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=2FDDD795-B713-41B8-A650-1CA06F027416@comcast.net \
    --to=paulkoning@comcast.net \
    --cc=Richard.Earnshaw@foss.arm.com \
    --cc=binutils@sourceware.org \
    --cc=gdb@sourceware.org \
    --cc=nickc@redhat.com \
    --cc=siddhesh@gotplt.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).