[ On Thursday, November 30, 2000 at 22:23:03 ( +0100), Ignatios Souvatzis wrote: ]
> Subject: Re: Addition to force open to open only regular files
>
> No. They are successful as the set ID because the code has set-ID priviliges.
> They are still successfull to get control over the original ID for non-setid
> programs.

Well, yeah, but if you can get control over your own original UID, then
exactly what have you gained?

I'm not talking about blocking remote buffer overflow exploits and
preventing them from having an impact when the code in question is doing
something without having properly authorised the remote user -- that's
really an authentication and authorisation problem, not an issue of
exploiting remote buffer overflows or whatever.

I.e. server programs which do properly authorise a fully authenticated
remote user will not be any more vulnerable to remote attacks than
similar programs would be to local attacks, and if they only give a user
access to his or her own identity, then the cracker gains nothing by
attacking the program in question.

The problem with remote buffer overflow types of attacks of non-set-ID
programs is that they can offer capabilities that should never be
offered without proper and complete authentication and authorisation.

A perfect example of such a stupid idea is the CVS pserver
implementation which uses a an insecure authentication and a fake
authorisation scheme to give a remote user privileges in the local
repository.  CVS-pserver is only barely useful for providing totally
anonymous read-only access, and then only if the user it runs as is
otherwise *completely* unprivileged on the server system.  In the latter
case it is only exploitable for CPU/core and maybe network resources,
but in the former case it gives any capable remote user total control
over the repository, and perhaps even more ability and privilege if the
server system has other local vulnerabilities.

Fingerd's an excellent example of a program which was once sometimes run
as a privileged user in some scenarios [eg. to get the contents of a
user's ~/.plan file when the user's $HOME was protected], but which
isn't a set-ID program.  Some monolithic mailers still run their SMTP
servers as root.  If such programs are vulnerable to any kind of bug
that allows insertion of unauthorised code into its process image then
any exploit of such a vulnerability will always be successful, and thus
if it's running as a privilged user then you lose big-time!  However if
it is run as a totally unprivileged user (as of course we've all learned
to do with fingerd, right!), then such exploits will only be able to
take control of any remaining resources still controllable by such an
unprivileged user (eg. some CPU time, core pages, and maybe the ability
to open new network connections, etc.).

So, yes, a remote exploit can still gain control over some types of
program's credentials, but at what real-world gain?  Presumably any
system manager worth his or her salt will have restricted the resources
available to such unprivileged users to the point where they cannot have
any adverse affect on the system.  Is it time to add further
restrictions on things like socket() such that unprivileged users can't
open unauthorised network connections too?  I've been thinking of such
issues for a long long time now, but as yet I've not encountered
exploits which necessitate such restrictions.  Perhaps discussing the
possiblity in a public forum is enough to force the requirement?

-- 
							Greg A. Woods

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