[Mod_nss-list] Problem 2

Jennings, Jared L CTR USAF AFMC 46 SK/CCI jared.jennings.ctr at eglin.af.mil
Wed May 4 23:07:42 UTC 2011


When FakeBasicAuth does not fill in a username and password from a
certificate, there's a mechanism which is supposed to prevent the user
from maliciously gaining access by typing a certificate-related
username, and the password 'password'. I don't think it works right in
mod_nss.

Around line 602 of nss_engine_kernel.c ("Make sure the user is not able
to fake"), nss_hook_UserCheck checks to see if the first character of
the username is '/'. Under mod_ssl with FakeBasicAuth, this is a
sufficient check, because certificate-based usernames always start with
'/'. (I believe mod_ssl ignores SSLUserName when FakingBasicAuth.) But
under mod_nss (nss_engine_kernel.c:486, 650, nss_engine_io.c:1371), the
username checked here is only the CN, and the CN doesn't start with '/'
- neither when it's legitimate nor when someone is trying to "fake the
client certificate based authentication." So the if at line 602 never
fires. 

Consequently, when I hit Reload a few times and I get that
username/password box (this is "problem 1" that I posted a bit ago), if
I know the common name of anyone else's certificate, under mod_nss I can
type it in, and use the password 'password', and become them.

The simplest way I can see to secure this would be: instead of making
sure there are no maliciously faked Authorization headers in the
request, make sure there are no Authorization headers at all. If we're
FakingBasicAuth, all the authentication should be coming from the
certificate. But this may not work unless all access is via certificate
- or if I don't understand the ways of Apache properly, may not work at
all.

Next simpler, instead of setting client_dn to NULL
(nss_engine_kernel.c:486, nss_engine_io.c:1371), come up with the same
slash-delimited, country-first distinguished name that mod_ssl does, and
set it instead of the common name. Perhaps don't set the common name as
a default anymore, because the client_dn will always be set. Then the
check at nss_engine_kernel.c:602 would work. The final user name may not
even have to be the client_dn: it appears that NSSUserName does its work
during fixup, so I'm authenticated with one name, but then REMOTE_USER
can be set to another.

I'm new to mod_nss, so I can't be sure that either is a good idea. Any
wisdom?




More information about the Mod_nss-list mailing list