Installing a compiler by default

[Cefiar]

On Wednesday 14 June 2006 04:57, Matt Zimmerman wrote:
> On Sat, Jun 10, 2006 at 02:41:52PM +1000, Cefiar wrote:
> > On Friday 09 June 2006 02:44, Matt Zimmerman wrote:
> > > I would like to propose that, beginning in Edgy, Ubuntu desktop systems
> > > (both live and installed) should, by default, include the set of
> > > packages necessary to compile simple C programs and Linux kernel
> > > modules.
> >
> > I think that if we do this, we need to provide some way of restricting
> > access to GCC. This removes most of the concern that people have, IMO.
>
> I can't really agree; I don't at all support the assertion that there is a
> security concern here, and even if I did, restricting access wouldn't solve
> the problem.

To me, it's not about solving a problem, more that it is about mitigating it 
to SOME extent.

> The usual argument that people make is that the availability of gcc makes
> it easier for a worm to compile exploits, rootkits and so forth for the
> target system.  This really isn't a sizeable barrier, though, and plenty of
> worms are written which cause plenty of destruction without a compiler.

Specifically, the ones that worry me are the cases where a program call can 
insert raw code into kernel memory, where it can then be pretty much 
invisible to standard user space. Sure, you don't need a compiler to do this, 
but it's usually a LOT easier to do with a compiler on the machine than 
without.
 
> Some easy ways to circumvent this "security" mechanism include:
>
> - Including instructions in the worm for installing a compiler (I can
> easily think of a sequence of less than 10 shell commands which would get a
> compiler installed on a majority of Linux systems, regardless of which
> distribution is in use)
>
> - It is possible (and indeed it has been done) to write exploits in a
>   language for which an interpreter is likely to be available on the system
>   already, such as Python.  We certainly shouldn't exclude Python because
> of this possibility, though!
>
> - It's even possible (and indeed it has been done) to write a C compiler in
>   Python, and to use that to compile an exploit.
>
> - It is possible (and indeed it has been done) to ship a simple C compiler
>   built for the target architecture.  It's pretty easy to build a simple
>   program which will run on any 32-bit Intel Linux system, which is a huge
>   majority

All of which actively require them to do just that, which would most likely 
take longer than if they had a compiler on the machine. Sometimes, this is 
time in which an exploit may actually be foiled, particularly when you start 
talking about previously unknown bugs being fixed and the details being 
publically exposed to the world.

An example in timing: I maintain a Drupal site for a linux user group. 
Recently there was a number of patches released to address previously unknown 
bugs. I saw the upgrade details hit the email list. I managed to patch the 
site in question before the website had updated. Within 1/2 hour of the 
website being updated, I saw logged details of failed attempts to exploit the 
flaw.

If it slows the attacker down long enough for a system to actually be patched 
against the flaw, then IMO it's useful. Sure it's better to not have the flaw 
in the first place, but we live in a flawed world, and that isn't going to 
change any time soon. That's not to say we shouldn't aspire and aim at no 
flaws, but from past experience we should not RELY on something having no 
flaws.

BTW: Despite all this, I'm in favour of having the compiler tools there, even 
if this hasn't been done.

-- 
 Stuart Young - aka Cefiar - cef at optus.net