[Mod_nss-list] Problem 2

[Rob Crittenden]

Jennings, Jared L CTR USAF AFMC 46 SK/CCI wrote:
> 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?

I agree that the code looking for / is a bug. mod_nss is a derivation 
from the mod_ssl code, this must be a piece I missed when implementing 
this originally. I'll take a look.

rob