Subject: Re: RFC: migration to a fully dynamically linked system
To: None <tech-userlevel@NetBSD.ORG>
From: None <xs@kittenz.org>
List: tech-userlevel
Date: 12/22/2001 10:31:25
on Sat, Dec 22, 2001 at 01:51:33AM -0500, Greg A. Woods wrote:
> Run-time checks inserted by the compiler (or linker) can easily block
> this attack, BTW, and at very little run-time cost.  If I remember the
> reference describing these techniques in more detail I'll post it....

Maybe you are talking about StackGuard?
http://www.wirex.com/Immunix/Guardian.html has an explaination and
other "guards"
http://www.phrack.org/show.php?p=56&a=5 breaks it.
I don't think stackguard protects function pointers either, soo..

Such schemes are no panacea, the only real way to stop overflows is to
find them and fix them. :)

> 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?
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)

> Indeed -- which is why privileged programs should only be written in a
> compiled language, following all the long list of rules we've learned
> the hard way over the years.  It's also why it's so damn important not
> to allow the code segments (i.e. the text areas) of processes
> (privileged or otherwise) not ever be allowed to be changed after the
> process starts.

We still don't know all the rules yet. deattack.c in sshd was written
by core-sdi (iirc), who are very clued in to security matters imho.
Yet their code was found to be exploitable.. (and "even" the OpenBSD
didn't spot this for a while.)

> That's what I'm interested in doing.  I want to block exploits that
> result in foreign code being injected into buggy programs.

At a guess, most people only need about 10-50 privileged programs.
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..