remote server and effective uid

[Dan Stromberg]

On Tue, Nov 16, 2010 at 9:37 AM, Tim Arnold <tim.arnold at sas.com> wrote:

> "Tim Harig" <usernet at ilthio.net> wrote in message
> news:ibs8h9$jmq$1 at speranza.aioe.org...
> > On 2010-11-15, Tim Arnold <a_jtim at bellsouth.net> wrote:
> >> On Nov 15, 10:41 am, Tim Harig <user... at ilthio.net> wrote:
> >>> On 2010-11-15, Tim Arnold <a_j... at bellsouth.net> wrote:
> >>>
> >>> > How can I enable the server process to write into the client's
> >>> > directories?
> >>> > If I change the inetd service to run as 'root', I guess that would
> >>> > work, but then the client couldn't remove the files put there after
> >>> > the request.
> >>>
> >>> Python provides os.setuid() and os.seteuid() which wrap the system
> >>> functions. See you systems man pages for these functions for more
> >>> information.
> >>
> >> Thanks -- that was a lot easier than I thought it was going to be.
> >> pass the client's uid in the message to the server like so
> >>
> >> argstring, local_dir, uid = message.split(':')
> >> os.seteuid(int(uid))
> >
> > I am not sure exactly what you are doing; but, I would advise great
> > caution as messing this up could easily open your system to exploitation.
> > Be very sure that you know what you are doing.
>
> I can see how that looks dangerous, but I think it's okay. I have inetd
> listening on a port and whatever it receives, it passes on to that line
> above "argstring, local_dir, uid message.split(':').  The argstring is
> parsed using 'argparse' the resulting list of args is passed to a Python
> class that can only do work for a specific set of args. I can't think of a
> way someone could pass in an evil argstring that could do anything but
> fail.
>
> Thanks for your reply, and if you still think it's dangerous please let me
> know.
>

What if an attacker passes something other than their own uid across a
socket to your inetd-launched process?  EG, what if they pass a 0 (for root)
instead of getuid()?

It might be fine in your case, but in many cases, it's a problem.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-list/attachments/20101116/5cdda8dc/attachment.html>