Re: Support for NSS as a libpq TLS backend - Mailing list pgsql-hackers

From Jacob Champion
Subject Re: Support for NSS as a libpq TLS backend
Date
Msg-id 7d6a23a7e30540b486abc823f7ced7a93e1da1e8.camel@vmware.com
Whole thread Raw
In response to Re: Support for NSS as a libpq TLS backend  (Daniel Gustafsson <daniel@yesql.se>)
List pgsql-hackers
On Tue, 2020-10-27 at 21:07 +0100, Daniel Gustafsson wrote:
> > On 20 Oct 2020, at 21:15, Andres Freund <andres@anarazel.de> wrote:
> > 
> > > +static SECStatus
> > > +pg_cert_auth_handler(void *arg, PRFileDesc * fd, PRBool checksig, PRBool isServer)
> > > +{
> > > +    SECStatus    status;
> > > +    Port       *port = (Port *) arg;
> > > +    CERTCertificate *cert;
> > > +    char       *peer_cn;
> > > +    int            len;
> > > +
> > > +    status = SSL_AuthCertificate(CERT_GetDefaultCertDB(), port->pr_fd, checksig, PR_TRUE);
> > > +    if (status == SECSuccess)
> > > +    {
> > > +        cert = SSL_PeerCertificate(port->pr_fd);
> > > +        len = strlen(cert->subjectName);
> > > +        peer_cn = MemoryContextAllocZero(TopMemoryContext, len + 1);
> > > +        if (strncmp(cert->subjectName, "CN=", 3) == 0)
> > > +            strlcpy(peer_cn, cert->subjectName + strlen("CN="), len + 1);
> > > +        else
> > > +            strlcpy(peer_cn, cert->subjectName, len + 1);
> > > +        CERT_DestroyCertificate(cert);
> > > +
> > > +        port->peer_cn = peer_cn;
> > > +        port->peer_cert_valid = true;
> > 
> > Hm. We either should have something similar to
> > 
> >             /*
> >              * Reject embedded NULLs in certificate common name to prevent
> >              * attacks like CVE-2009-4034.
> >              */
> >             if (len != strlen(peer_cn))
> >             {
> >                 ereport(COMMERROR,
> >                         (errcode(ERRCODE_PROTOCOL_VIOLATION),
> >                          errmsg("SSL certificate's common name contains embedded null")));
> >                 pfree(peer_cn);
> >                 return -1;
> >             }
> > here, or a comment explaining why not.
> 
> We should, but it's proving rather difficult as there is no equivalent API call
> to get the string as well as the expected length of it.

I'm going to try to tackle this part next. It looks like NSS uses RFC
4514 (or something like it) backslash-quoting, which this code either
needs to undo or bypass before performing a comparison.

--Jacob

pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: Yet another fast GiST build
Next
From: Tom Lane
Date:
Subject: Re: pg_preadv() and pg_pwritev()