You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@httpd.apache.org by Marc Slemko <ma...@znep.com> on 2000/11/02 07:04:15 UTC

Re: Apache ap_getpass vulnerability

I don't consider this much of a bug in ap_getpass and don't see how anyone
could exploit it, but... wouldn't hurt to have ap_getpass zero out the
return from getpass.  

And do we have any way for marking non-threadsafe functions?  I don't see
how you could ever care if ap_getpass is threadsafe (well, I do, but I'll
ignore that...) but it would be nice to document that it isn't, at least
on most OSes.

---------- Forwarded message ----------
Date: Wed, 1 Nov 2000 09:28:58 -0800
From: "Jon Paul, Nollmann" <si...@DARKWATER.COM>
To: VULN-DEV@SECURITYFOCUS.COM
Subject: Re: Apache ap_getpass vulnerability

Sprach Simon =?iso-8859-2?Q?Tam=E1s?= <si...@WESTEL900.HU>:
> The Apache API ap_getpass function is a wrapper around the Os's
> getpass()
> function - in case it exists, or defines their own implementation of
> getpass.
[...]
> Apache doesn't do this "zeroing" so it's possile to get this value.

getpass() returns a string read from the user.  The ap_getpass()
buffer checks for buffer overflow and copies no data if the
user-supplied data is too long.  The only other interesting
possibility is looking at the values of passwords that _other_ people
have typed.

If you could trick the buffer overflow check, then there's a
possibility of passing interesting values through getpass().  You run
apache yourself, do what's necessary to trick getpass(), and then
apache does what you want.  The buffer overflow check is of type
size_t, which on all the systems I have access to is unsigned int.
That means we have to pass a LOT of data in order to trick the check.
In any case, unless apache is setuid/setgid, this doesn't give us
any new access.

On sane operating systems, the string is read directly from /dev/tty:
no redirection possibilities there.  On windows, the apache-provided
getpass() routine uses _getch() to get characters, so there's probably
a redirection possibility there.  So on windows, maybe we could trick
an already running apache into reading a password from us?

The other possibility is in getting passwords that other people have
typed.  That entails finding an apache to which someone has typed a
password, and making it coredump.  Maybe we could trick a module into
displaying the data for us, but I think coredump is the best bet.  We'll
need a buffer overflow exploit to do that, since we can't send signals
to the apache.

The only pieces of code in the standard apache distribution that calls
ap_getpass() is htdigest and htpasswd.  Maybe we could set things up
so that one of those programs crashes the next time it runs?  But
unfortunately, if I, as an admin, run something and it crashes after I
type a password, I'm going to immediately suspect an attack (I'll prolly
be wrong, but better safe than sorry).

--
Jon Paul Nollmann ne' Darren Senn                      sinster@balltech.net
Unsolicited commercial email will be archived at $1/byte/day.
The optimist proclaims that we live in the best of all possible worlds; and
the pessimist fears this is true.
                             James Branch Cabell, The Silver Stallion, 1926



---------- Forwarded message ----------
Date: Sat, 1 Jan 2000 05:24:04 +0100
From: "Simon [iso-8859-2] Tam�s" <si...@westel900.hu>
To: VULN-DEV@SECURITYFOCUS.COM
Subject: Apache ap_getpass vulnerability

Hi

I found this possible vulnerability in Apache 1.3.14 (latest version)
It effects apache modules that call the ap_getpass function on Unix
platforms.
It probably exists in earlier releases, though I haven't checked.

The Apache API ap_getpass function is a wrapper around the Os's
getpass()
function - in case it exists, or defines their own implementation of
getpass.

qutoe from getpass manual:

The getpass function leaves its result in an internal static object and
returns a pointer to that object.  Subsequent calls to getpass will
modify the same object.
The calling process should zero the password as soon as possible to
avoid leaving the cleartext password visible in the process's address
space.

Apache doesn't do this "zeroing" so it's possile to get this value.

What do you think?

Regards
S.T.