This is the mail archive of the
mailing list for the GCC project.
Re: 3.2 PATCH: Ada parallel bootstrap fixes
- From: Florian Weimer <fw at deneb dot enyo dot de>
- To: kenner at vlsi1 dot ultra dot nyu dot edu (Richard Kenner)
- Cc: gcc at gcc dot gnu dot org
- Date: Sat, 18 May 2002 16:06:58 +0200
- Subject: Re: 3.2 PATCH: Ada parallel bootstrap fixes
- References: <10205181344.AA00624@vlsi1.ultra.nyu.edu>
firstname.lastname@example.org (Richard Kenner) writes:
> 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.
This isn't always necessary (e.g., for /tmp issues on multiuser
> (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.
There are also different, less grave security problems, for example
denial of service vulnerabilities or information leaks. Unauthorized
privilege escalation is just one security problem, but there are
> 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.
For the vulnerabilities I've reported so far, no special code is
required on the application side, it is sufficient that the
application calls the vulnerable code (which happens if you create a
temporary file using the standard Ada way, for example).
It is unfortunate that there is so little Ada usage. Otherwise, we
would have dozens of applications at hand to demonstrate that this is
a real problem, and not just some random irrelevant issue that turned
up during a code audit.
Remember that similar problems have been fixed in C libraries years
ago. Should we really wait until Ada programms are bitten by the same