]> granicus.if.org Git - postgresql/commit
Remove arbitrary limitation on length of common name in SSL certificates.
authorTom Lane <tgl@sss.pgh.pa.us>
Thu, 23 Feb 2012 20:48:09 +0000 (15:48 -0500)
committerTom Lane <tgl@sss.pgh.pa.us>
Thu, 23 Feb 2012 20:48:09 +0000 (15:48 -0500)
commite6fcb03dc0de1771f7d408b5df1738272e6f98e5
treec786e27946eb8c619c9c8098a8539fb3adbdf410
parent54e2b6488bb294691a525a272d6f614ac2046282
Remove arbitrary limitation on length of common name in SSL certificates.

Both libpq and the backend would truncate a common name extracted from a
certificate at 32 bytes.  Replace that fixed-size buffer with dynamically
allocated string so that there is no hard limit.  While at it, remove the
code for extracting peer_dn, which we weren't using for anything; and
don't bother to store peer_cn longer than we need it in libpq.

This limit was not so terribly unreasonable when the code was written,
because we weren't using the result for anything critical, just logging it.
But now that there are options for checking the common name against the
server host name (in libpq) or using it as the user's name (in the server),
this could result in undesirable failures.  In the worst case it even seems
possible to spoof a server name or user name, if the correct name is
exactly 32 bytes and the attacker can persuade a trusted CA to issue a
certificate in which that string is a prefix of the certificate's common
name.  (To exploit this for a server name, he'd also have to send the
connection astray via phony DNS data or some such.)  The case that this is
a realistic security threat is a bit thin, but nonetheless we'll treat it
as one.

Back-patch to 8.4.  Older releases contain the faulty code, but it's not
a security problem because the common name wasn't used for anything
interesting.

Reported and patched by Heikki Linnakangas

Security: CVE-2012-0867
src/backend/libpq/be-secure.c
src/include/libpq/libpq-be.h
src/interfaces/libpq/fe-secure.c
src/interfaces/libpq/libpq-int.h