This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: 3.2 PATCH: Ada parallel bootstrap fixes (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

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]