[tpop3d-discuss] Re: OpenSSL and POP3 Integration Question (fwd)

[Ben Schumacher]

Chris-

As I wasn't 100% certain what the answer was with regards to your previous
email about TLS support, I decided to defer to the experts on the OpenSSL
mailing list. I'm forwarding two emails that I received in response to my
query to this list.

Here is the first:

---------- Forwarded message ----------
Date: Mon, 21 Jan 2002 12:28:05 +0100
From: Lutz Jaenicke <Lutz.Jaenicke@aet.TU-Cottbus.DE>
Reply-To: openssl-users@openssl.org
To: openssl-users@openssl.org
Subject: Re: OpenSSL and POP3 Integration Question

On Fri, Jan 18, 2002 at 10:10:36AM -0700, Ben Schumacher wrote:
> I am trying on integrating OpenSSL into a POP3 daemon that I've been
> contributing to, and a security concern has come up that I hadn't
> considered but has me curios. Basically, as with most POP3 daemons,
> after authentication, the program forks an external process and does a
> setuid to the authenticated user's UID. This behavior is fairly ubiquitous
> in these types of daemons, as it helps the daemon deal with some other
> security issues.
> 
> However, with SSL it allows for the possibility that a user logged
> into the system could launch a debugger and hook into the fork()'d
> process, and view some of the cryptographic information. Would this expose
> the private key used during the key exchange to be seen by an unauthorized
> user? Is it possible that we could free the memory used to store the
> private key before the fork() and avoid this issue? I admit that I don't
> have enough knowledge of SSL/TLS to know whether the private key is used
> during renegotiation. I looked through the RFC (2246), and couldn't find a
> definitive answer (although, this could be because I started getting
> confused).

We are facing 2 questions;
* The OpenSSL API does not offer a call to remove the private key
  information from memory as long as any TLS functionality is still
  set up.
  (-> reminder: check, whether the memory overwritten when performing
  SSL_free()/SSL_CTX_free()..)
  To be compliant with RFC2246 we do not the private key, as a
  renegotiation may take place.
* On the other hand, if your process started with root permissions
  and later dropped privileges using setuid(), your kernel should protect
  you from the user being able to attach to it.
  (At least on HP-UX: I just tried to attach to an imapd process
  and the kernel did not allow it.)

Best regards,
	Lutz
-- 
Lutz Jaenicke                             Lutz.Jaenicke@aet.TU-Cottbus.DE
http://www.aet.TU-Cottbus.DE/personen/jaenicke/
BTU Cottbus, Allgemeine Elektrotechnik
Universitaetsplatz 3-4, D-03044 Cottbus
______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
User Support Mailing List                    openssl-users@openssl.org
Automated List Manager                           majordomo@openssl.org