Re: Apache ap_getpass vulnerability

[Peter Pentchev <roam () ORBITEL BG>]

On Sun, Jan 02, 2000 at 10:03:27PM +0100, Simon Tamas wrote:
> Please imagine this situation:
>
> You have an apache module that communicates via SSL with some other
> server.
> Your module reads the configuration necessary for the SSL setup from the
> Apache
> configuration file. There will be things like:
> CA certificate
> client certificate
> private key
>
> The private key is usually password protected. So if someone get access
> to it
> he won't be able to use it unless he knows the password.
> These files are stored on the same machine where the Apache runs,
> probably in the
> conf directory.
>
> If your modules needs to use the private key it needs to get the
> password for it,
> so it calls ap_getpass()
> This however calls getpass() which stores the password in a static char*
> and returns
> that pointer. It should be ap_getpass's (or your modules) responsibility
> to copy that
> string and fill the memory pointed to by the char* with useless values.
>
> Unless this is done somebody who gets access to the webserver machine,
> and therefore can
> read the private-key file, can also crash the Apache in such a way that
> he can read the
> password from memory. All he has to know is where the static char*
> inside getpass is in
> memory.

In all probability, someone will have beat me to this answer, but oh well.

No, Apache (the webserver) can NOT call ap_getpass().  ap_getpass()
(and the underlying getpass()) is called for applications running
*on a terminal*, to read user's passwords *interactively*.  The webserver
reads all 'user input' (the HTTP query, its header, arguments, body)
from the network; there is no way the webserver shall wait for keyboard
input on the socket.  This is the browser's - client's - job.

To repeat Jon Poll's statement, the only place where ap_getpass() is called
is in htpasswd and htdigest, which just happen to be the only binaries
in the Apache distribution that should ever require interactive user input.
The SSL modules would have to find another way to validate keys having
at their disposal only the client's query and TCP connection credentials
(not that there are too many of those..)

G'luck,
Peter

--
This sentence contradicts itself - or rather - well, no, actually it doesn't!