Re: Policy for posting security bug reports?

[Mike Frysinger <vapier at gentoo dot org>]

On Saturday 23 June 2012 20:50:35 Rich Felker wrote:
> On Sat, Jun 23, 2012 at 06:31:17PM -0400, Mike Frysinger wrote:
> > On Saturday 23 June 2012 09:55:51 Petr Baudis wrote:
> > > policy there? E.g. for gcc, binutils (probably not too many security
> > > bugs in these two), coreutils, ...?
> > 
> > gcc & binutils pretty explicitly don't have security paths.  bugs are
> > bugs to them.  probably because it's fairly easy to crash them, and they
> > don't get run in the same situations as the C library.
> 
> gcc/binutils bugs could be serious security issues if you're using
> distcc and you don't entirely trust your clients.

perhaps, but the point still stands -- it is fairly trivial to make 
binutils/gcc crash in pretty much every release, and neither project today 
cares about treating security bugs specially.

if you want to allow untrusted clients to execute arbitrary input, then you'll 
need to setup things accordingly.  especially considering you can do things 
like:
$ cat test.S
.incbin "/etc/passwd"
$ distcc gcc -c test.S
$ strings test.o
(yes, i know /etc/passwd is meant to read by anyone, but my point is that you 
can get distcc to read any file on the system with lax permissions which people 
might not expect)

or trivial to control the output (and thus clobber arbitrary files):
$ distcc gcc -c test.S -Wa,-o,/some/path,-I -o -D
(this will write the output to /some/path)

i imagine there are plenty of other flags to do fun things like this since 
there are compiler, preprocessor, and assembler flags to choose from.  i don't 
think distcc runs the linker in parallel, otherwise that'd open up even more 
stuff.
-mike

Attachment: signature.asc
Description: This is a digitally signed message part.