This is the mail archive of the
mailing list for the GCC project.
Re: 3.2 PATCH: Ada parallel bootstrap fixes
- From: Paul Koning <pkoning at equallogic dot com>
- To: kenner at vlsi1 dot ultra dot nyu dot edu
- Cc: fw at deneb dot enyo dot de, gcc at gcc dot gnu dot org
- Date: Sat, 18 May 2002 10:53:33 -0400
- Subject: Re: 3.2 PATCH: Ada parallel bootstrap fixes
- References: <10205181344.AA00624@vlsi1.ultra.nyu.edu>
Excerpt of message (sent 18 May 2002) by Richard Kenner:
> So prove me wrong, please. So far, I've seen nothing in this
> In normal usage, a "security problem" refers to a bug in a program that will
> enable somebody to use that program to gain access to which they are not
> entitled. This can only happen if the program in question has some
> special access, such as being setUID to root or running as root as a daemon.
That's fine for programs.
> By this definition, a problem in a *library* cannot be a "security
> problem" by itself. You have to have two conditions met for it to
> become a security problem:
> (1) A program using that library is run setUID root or as a daemon.
> (2) The program has to be written in such a way that the potential
> buffer overflow in the library routine results in being able to give
> its higher access to an intruder.
> Only a very small handful of programmers ever write programs that meet #1
> above and Ada is rarely used for them (I'm not saying we want to discourage
> Ada from being used in such, just stating the present situation) and they
> would then also have to have flaw #2.
I think this reasoning is exactly backwards for libraries. Libraries
have to be held to a stricter standard.
A library is potentially used with lots of programs. Each program
that uses it is potentially a "special access" program in the sense
you described. If 100 programs use the library, that's 100 chances
for this condition to hold. Any one of those is sufficient to allow
an actual attack.
I also find it ironic to see this discussion in the context of Ada --
which after all has as its major claim to fame its supposed fitness
for creating highly reliable ("mil spec") software. If that is valid,
then the response to any flaws like this should be more aggressive
than with "ordinary" programming languages.