Vulnerability Development mailing list archives
Re: Apache ap_getpass vulnerability
From: Peter Pentchev <roam () ORBITEL BG>
Date: Thu, 2 Nov 2000 21:16:25 +0200
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!
Current thread:
- Apache ap_getpass vulnerability Simon Tamás (Nov 02)
- Re: Apache ap_getpass vulnerability Jon Paul, Nollmann (Nov 03)
- Re: Apache ap_getpass vulnerability Simon Tamás (Nov 03)
- Re: Apache ap_getpass vulnerability Jon Paul, Nollmann (Nov 04)
- Re: Apache ap_getpass vulnerability Pavel Kankovsky (Nov 05)
- Re: Apache ap_getpass vulnerability Simon Tamás (Nov 07)
- Re: Apache ap_getpass vulnerability Peter Pentchev (Nov 05)
- Re: Apache ap_getpass vulnerability Simon Tamás (Nov 04)
- Re: Apache ap_getpass vulnerability Peter Pentchev (Nov 05)
- Re: Apache ap_getpass vulnerability Carson Gaspar (Nov 06)
- Re: Apache ap_getpass vulnerability Jon Paul, Nollmann (Nov 06)
- Re: Apache ap_getpass vulnerability Carson Gaspar (Nov 06)
- Re: Apache ap_getpass vulnerability Michael H. Warfield (Nov 07)
- Re: Apache ap_getpass vulnerability Jon Paul, Nollmann (Nov 07)
- Re: Apache ap_getpass vulnerability Lincoln Yeoh (Nov 08)
- Re: Apache ap_getpass vulnerability Bluefish (P.Magnusson) (Nov 10)
- Re: Apache ap_getpass vulnerability Simon Tamás (Nov 03)
- Re: Apache ap_getpass vulnerability Jon Paul, Nollmann (Nov 03)
- Re: Apache ap_getpass vulnerability Bluefish (P.Magnusson) (Nov 06)