The NSSCipherSuite option of modnss accepts OpenSSL-styled cipherstrings. It was found that the parsing of such cipherstrings is flawed. If this option is used to disable insecure ciphersuites using the common "!" syntax, e.g.:

NSSCipherSuite !eNULL:!aNULL:AESGCM+aRSA:ECDH+aRSA

it will actually enable those insecure ciphersuites.

Acknowledgements:

This issue was discovered Hubert Kario of Red Hat.

It was reported that modnss is vulnerable to the issue similar to CVE-2015-3276, where incorrect parsing of multi-keyword cipherstring can lead to an unexpected ciphers list advertising.

Acknowledgements:

Red Hat would like to thank Martin Poole of Software Maintenance Engineering group for reporting this issue.

A flaw was reported in the way modnss handled FakeBasicAuth NSSOption. Unlike modssl, modnss only used CommonName from a client certificate's subject, rather than the whole subject DN. This made safety check inherited from modssl that ensured client can not submit username and password generated by FakeBasicAuth via Authorization header without actually providing valid client certificate. Further details are in the Jared Jennings' post to the modnss mailing list:

https://www.redhat.com/archives/modnss-list/2011-May/msg00001.html

Problem was corrected in the following upstream git commit:

https://git.fedorahosted.org/cgit/modnss.git/commit/?id=a6c3370491ae1d3bc552e8de9353c82f73e510e3

This fix is not yet included in any released modnss version. The last released version to date is 1.0.8 from Jul 2008.

This problem was already corrected in Red Hat Enterprise Linux 5 and 6 modnss packages via the following errata:

https://rhn.redhat.com/errata/RHBA-2011-1656.html https://rhn.redhat.com/errata/RHBA-2013-0009.html

A flaw was found in the way NSSVerifyClient was handled when used in both server / vhost context as well as directory context (specified either via <Directory> or <Location> directive). If 'NSSVerifyClient none' was set in the server / vhost context (i.e. when server is configured to not request or require client certificate authentication on the initial connection), and client certificate authentication was expected to be required for a specific directory via 'NSSVerifyClient require' setting, modnss failed to properly require expected certificate authentication. Remote attacker able to connect to the web server using such modnss configuration and without a valid client certificate could possibly use this flaw to access content of the restricted directories.

Documentation of modnss configuration directives, including NSSVerifyClient:

https://git.fedorahosted.org/cgit/modnss.git/plain/docs/modnss.html#Directives

As modnss is derived form modssl, NSSVerifyClient is meant to be functionally equivalent to modssl's SSLVerifyClient:

http://httpd.apache.org/docs/2.2/mod/modssl.html#sslverifyclient