TLS Support (was- Re: [tpop3d-discuss] Compilation trouble on Solaris)

[Ben Schumacher]

On Thu, 17 Jan 2002, Chris Lightfoot wrote:
> Hmm. First, I should apologise for throwing the above in
> to the mix without getting in touch with you first.

Not a big deal... just really like tpop3d (I looked at about 10 POP3
daemons before choosing this one), and wanted to know if there was
anything I could do to make it better.

> However, there is a serious problem with TLS, which makes
> it unsuitable for use in a program such as tpop3d which
> uses blocking IO: a call to SSL_write may discover that
> the client has requested TLS renegotiation. This means
> either that the server could then block on SSL_read, or
> that all IO must be rewritten to be nonblocking. (The
> problem is, obviously, that although this doesn't have a
> serious effect when clients and the network are
> well-behaved, it's disastrous in the presence of a
> malicious client.) Now, it's certainly possible to rewrite
> tpop3d's main loop to use nonblocking IO and to include
> all of the TLS nastiness, but it's not a very pleasant
> problem and I'm reluctant to do this for another reason
> which I mention below.

That would be a problem. However, I did discover another potential DoS
problem that I introduced with my TLS patch that I missed during my
initial testing -- something I probably never would have though of if I
hadn't just run into a similar issue for an OpenSSL TLS product I've been
building for my job. And I understand fully your reluctance to rewrite as
non-blocking... aside from security concerns, it would take a major amount
of rework on the internals of the code.

> My thinking is that the best solution is to have tpop3d
> fork a `helper' process to do the TLS operations. This has
> another advantage: if the helper process runs as (say)
> root, a malicious local user cannot then use a debugger to
> steal valuable cryptographic data from the server process.
> This is pretty nasty, but is IMO a cleaner solution than
> the other options.

While I understand the security concern, I think the impact would be
limited. While it would allow users to view cryptographic information on a
tpop3d process that has already done setuid'd to the user in question,
would this really be all that bad? At worst it would expose information on
the private key used for the initial key exchange, but this problem could
probably be mitigated by making sure that memory is free'd or clobbered
before we change the effective UID of the forked process. Otherwise, it
would expose some information on the key selected that POP3 session, but
after that session has been closed that key should never be used
again. (Or at least, the probabilities of selecting that key again are
extremely low.)

If this solution is the choosen one, however, my suggestion would be to
run the external process as an unprivileged user that is defined in the
configuration file. While I have looked at your code and have seen that
you do very careful bounds checking, I still worry about the possibility
of buffer overruns and malicious code that might allow some sort of access
with root privileges.

Wow... a more than I was planning to write, but things just came to me as
I started typing.

Any of this make sense to anybody else?

Ben