This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: GCC 3.0.3 PRs
- From: Joe Buck <jbuck at synopsys dot COM>
- To: mark at codesourcery dot com (Mark Mitchell)
- Cc: jbuck at synopsys dot COM (Joe Buck), gcc at gcc dot gnu dot org (gcc at gcc dot gnu dot org),toon at moene dot indiv dot nluug dot nl (toon at moene dot indiv dot nluug dot nl),bkoz at redhat dot com (bkoz at redhat dot com)
- Date: Fri, 7 Dec 2001 15:22:34 -0800 (PST)
- Subject: Re: GCC 3.0.3 PRs
I wrote:
> > I think that 3720 should be considered a must-fix. If people use stream
> > I/O in security-critical programs, this kind of buffer overflow could lead
> > to root exploits in programs that would be perfectly safe with a
> > correct iostreams implementation. I don't think it's ethical for us to
> > ship with such a bug.
Mark writes:
> Well, OK. Of course, any code-gen bug could lead to the same kinds
> of problems. Still, I see your point.
This one is bad because it's pervasive: *any* attempt to read a number
can trigger a buffer overflow. The only workaround is for people not
to use stream I/O to read numbers *at all*. It's that bad. Even
int i;
cin >> i;
can be made to crash, just type a whole lot of digits. (I haven't
verified whether it's possible to force the program to execute arbitrary
code, but I wouldn't be surprised if it is).
> > Also, it shouldn't be hard to fix it once agreement is reached on how.
> > All that's needed is an upper bound on buffer size.
>
> Benjamin, can you work on this ASAP? Otherwise, I'll threatent to
> engineer my own quick fix for the branch to make Joe happy, but you'll
> probably not like how I do it. :-)
There's already a fix in the trunk, but it appears to be incorrect and slow.
Still, it's better than nothing.