Re: Is starting a user program on priv port via inetd dangerous ?

[avalon () coombs anu edu au (Darren Reed)]

[...]
> > My question is this: I own /home/dougmc/ircd/ircd, so I can change it
> > in any way I want.  Is it possible to alter it in such a way that it
> > takes this open fd to port 194 and abuses it, perhaps uses it to spoof
> > a rlogin or rsh?
>
> A quick perusal of (4.3BSD) inetd shows that it forks, the child
> gets setuid & setgid to the user that ircd is supposed
> to run as (dougmc in this case), and exec()d.  Doesn't
> look too bad, but I just glanced at the code, and I couldn't
> say if any other version of UNIX doesn't do something dumb in inetd.

I think you misunderstood the question.

What he was asking about is replacing ircd with a trojan which would then
use the open port to connect as rlogin or similar.

Your average BSD rlogind will check the port the connection comes from, so
I assume they all do when they come from your trusty vendor, to make sure
it is within the range 512 to 1024, or more precisely, the upper half of
whatever it believes is the range for priviledged ports to be (there's a
kernel variable on Solaris2 for this...I'm curious about what happens when
this becomes 0 :-)

So straight away, this puts 194 out of the market.

What if it were 594 ?

Well, that's a bit more interesting, but unfortunately, you can't perform a
connect(2) on a socket (such as the one which inetd will pass you if you
specify "wait" for a "stream") after the listen(2) call has been made on
it.  I've tried this with other port numbers, and no go.

Now what I don't know, is what happens when listen() and connect() are NOT
kernel system calls (such as with Solaris2).  They're an interface to
ioctl's (I believe) which do the dirty work that listen(2) and friends used
to do.  Is it then possible to "undo" those ioctl's ?  (Nearly all ioctl's
are reversible as they clear/set flags or similar).  Anyone ?