Re: pre-connect and smtp ?

[Brian Stafford <brian stafford uklinux net>]

On Mon, 20 August 09:42 M . Thielker wrote:
> Hi,
> 
> On 2001.08.20 12:43 Brian Stafford wrote:
> > There is another problem with port forwarding though, nothing to do with
> > ssh.
> > That is port numbers are a global resource for a given host.  Once the
> > host is listening on the port, any user can try to connect to that port.
> > This may be undesirable.  Even if the port forwarding program accepts only
> > one connection, there is still a critical race when another client
> > connects
> > before the one that set up the connection.  That client can then
> 
> Well, that's true only for other users on the local host.

No reason to assume they will be nice to you.

> The listening port
> is always bound to 127.0.0.1. This is not an option, it's hardcoded. So,
> only processes on the local host can use the tunnel.

That does not alter the security implications.  This is about as secure
(under the port forwarding situation we are discussing) as having world
write permission on /dev/kmem.

> Normally it is assumed that the tunnel would be used to encrypt a session
> with a remote server requiring separate authentication. Therefore, if
> another user on the local host connected to that port instead of the
> legitimate user, he would still have to face the login prompt of the
> protocol in question.

SMTP does not work like this.

> So, used as intended it's relatively safe.

SMTP does not match the ssh tunnel operating model very well.

> If the
> originating host is a desktop machine, security is even greater since
> desktops usually don't permit remote logins, so there is only the console
> user.

Hmmmm... I disagree.  maybe I'm just paranoid.
> 
> > socket on the localhost though.  This still isn't as good as forwarding
> > stdin/out to a remote host port, which ssh can't do either.
> 
> That also has it's pitfalls because inetd will accept mutilple connections
> from any host and would then forward those. With inetd, it would be even
> less secure because you cannot specify an address to bind to on a
> protocol-per-protocol basis. xinetd offers more security, allowing to limit
> the addresses a listener is bound to and the clients that may connect.

Using x?inetd has the same problems as ssh -L ...  I was thinking of the
situation
where libESMTP forks/execs a program which runs an SMTP session on its
stdin/out.
sendmail -bs does this.  Such a program could also be a tunnel to a remote
SMTP server.  This would require new code in libESMTP.  To date I haven't
written it because I havent been able to justify doing so.

> Not if it's used within it's design parameters. When abused, almost
> everything becomes a Bad Thing.

Too right.  Since SMTP is a store and forward protocol using it with almost
anything designed for a session mode protocol could be considered abuse.

Brian