[ On Saturday, December 22, 2001 at 10:31:25 (+0000), xs@kittenz.org wrote: ]
> Subject: Re: RFC: migration to a fully dynamically linked system
>
> Such schemes are no panacea, the only real way to stop overflows is to
> find them and fix them. :)

Of course -- I'm not suggesting we try to stop overflows.  I'm only
suggesting that we take away at least their sharpest and most damaging
edges.

There is no magic pill.  There is no absolutely perfect solution.  I'm
not looking for one, and people must stop executing one to be found.

However unless at least these measures are taken (provide mechanisms to
automaticaly protect text areas from modification and prevent the
program counter from jumping anywhere but a protected text area, and
another to verify return addresses before loading them into the program
counter) then the most damaging and easiest existing exploits will
continue to happen because new overflow bugs will continue to be found.
We must raise the bar to get to the next level.

> > A daemon that execs /bin/sh is not a well
> > written one.  (wasn't there a bug related to the use of system(3) in
> > some poorly written fingerd reported the other day on BUGTRAQ?)
> 
> sshd, telnetd?

no, it was a fingerd....  and it did call system().  I was personally
interested because I maintain a version of fingerd, one which does not
call system() even though it does provide a dangerous, but very
optional, feature similar to the one with the reported bug.  :-)

> The exec'ing of /bin/sh only needs to be in a library or file that is
> mapped in. So system(3) is a nice target for finding the appropriate
> code. Which basically means anything linked against libc probably has
> the appropriate code lying around. (although I haven't checked this)

Of course.  My point was that no privileged daemon (of which every
network daemon is by definition, even if it runs as "nobody", because
any unauthorised access to the inside of a remote system is more
privileged than no access) should ever exec /bin/sh, and especialy never
by calling system(3).  (with exceptions of course sshd must exec a shell
if it's to be of any use :-)

If that means they must all be linked statically, then so be it.  :-)

> We still don't know all the rules yet.

I don't think I made any such claim, but you're very right to point it
out explicitly!  :-)

> At a guess, most people only need about 10-50 privileged programs.

Be careful how you define "privileged".  See above about fingerd.

Every program that might be run as the superuser will be running
privileged.  This is yet another reason never to do ordinary things as
root, perhaps an even more important reason than the old wive's tale
about reducing the collateral damage from one's mistakes.

> It doesn't do any harm for those worried enough to at least skim the
> code, applying those rules you refered to above. The more programs
> you skim, the more knowledgable you become, and the most bugs
> you are likely to find..

You still can't force people to only run audited code.  With a pervasive
public Internet you have to be just about as concerned about everyone
else as you are about yourself.  Almost any attacker can use the faults
in any number of other systems to gang up on you no matter how perfect
your code is.

-- 
								Greg A. Woods

+1 416 218-0098;  <gwoods@acm.org>;  <g.a.woods@ieee.org>;  <woods@robohack.ca>
Planix, Inc. <woods@planix.com>; VE3TCP; Secrets of the Weird <woods@weird.com>