On 12 Jan 2002, Kai Henningsen wrote:
> > This means that an unprivileged user could open up the server to
> > non-privileged ports. I think this is probably a bit of a security
> > exposure that some people would not like.
>
> I don't see any problem, here.
>
> What security is lost when you can do the exact same thing you can do over
> port A also via port B, with the exact same security once connected?
Consider an Exim server that is listening on port A and port B (Exim 4
can listen on more than one port at once) and providing different
services on them. What should it do with a connection on port C? The
admin won't be expecting this, and will no doubt implement a
configuration of the form "if port A then xxx else yyy". I think it
isn't a good idea to have this possibility.
> Especially as any firewall would only let port A through anyway.
One cannot presuppose a firewall. Not everybody has them.
The suggestion has been made that the test should be "if port < 1024",
which seems to me to be a good compromise.
> Remember, with a TCP connection, you can always find out the port and ip
> address of both sides (modulo masquerading and so on, of course). You
> could, for example, make Exim reject any connection whose local port
> wasn't the SMTP port, assuming the SMTP port to be guarded by the
> priviledge necessary to open it.
Indeed. That's a tighter variant on the suggestion above. I had
overlooked the possibility of testing the port.
--
Philip Hazel University of Cambridge Computing Service,
ph10@??? Cambridge, England. Phone: +44 1223 334714.
