Re: anole - test case sha2 fails on all branches

On Thu, Apr 23, 2015 at 6:13 AM, Sandeep Thakkar
<sandeep.thakkar@enterprisedb.com> wrote:
> The test case sha2 in contrib pgcrypto module is failing with a diff on
> anole because the results file contains the additional lines as:
> --
>
> + WARNING:  detected write past chunk end in ExprContext 600000000021cbb0

That's clearly a bug, but it's a little hard to tell which commit
introduced it because anole hasn't reported in so long.  :-(

I notice that friarbird, leech, markhor, and jaguarundi are failing
with changes that appear to be clearly RLS-related:

http://www.pgbuildfarm.org/cgi-bin/show_log.pl?nm=friarbird&dt=2015-04-23%2004%3A20%3A00
http://www.pgbuildfarm.org/cgi-bin/show_log.pl?nm=leech&dt=2015-04-23%2003%3A47%3A14
http://www.pgbuildfarm.org/cgi-bin/show_log.pl?nm=markhor&dt=2015-04-23%2000%3A00%3A12
http://www.pgbuildfarm.org/cgi-bin/show_log.pl?nm=jaguarundi&dt=2015-04-22%2020%3A03%3A09

There are lots of machines failing in pg_upgradeCheck, but I don't see
details of the failures in the logs.

I suppose whatever's going wrong on anole must be the result of a
commit that was back-patched all the way to 9.0, post November 30th,
and probably touching contrib/pgcrypto.  That seems to include the
following four commits:

Author: Noah Misch <noah@leadboat.com>
Branch: master [8b59672d8] 2015-02-02 10:00:45 -0500
Branch: REL9_4_STABLE Release: REL9_4_1 [258e294db] 2015-02-02 10:00:49 -0500
Branch: REL9_3_STABLE Release: REL9_3_6 [a558ad3a7] 2015-02-02 10:00:50 -0500
Branch: REL9_2_STABLE Release: REL9_2_10 [d1972da8c] 2015-02-02 10:00:51 -0500
Branch: REL9_1_STABLE Release: REL9_1_15 [8d412e02e] 2015-02-02 10:00:52 -0500
Branch: REL9_0_STABLE Release: REL9_0_19 [0a3ee8a5f] 2015-02-02 10:00:52 -0500
   Cherry-pick security-relevant fixes from upstream imath library.
   This covers alterations to buffer sizing and zeroing made between imath   1.3 and imath 1.20.  Valgrind Memcheck
identifiedthe buffer overruns   and reliance on uninitialized data; their exploit potential is unknown.   Builds
specifying--with-openssl are unaffected, because they use the   OpenSSL BIGNUM facility instead of imath.  Back-patch
to9.0 (all   supported versions).
 
   Security: CVE-2015-0243

Author: Noah Misch <noah@leadboat.com>
Branch: master [1dc755158] 2015-02-02 10:00:45 -0500
Branch: REL9_4_STABLE Release: REL9_4_1 [82806cf4e] 2015-02-02 10:00:49 -0500
Branch: REL9_3_STABLE Release: REL9_3_6 [6994f0790] 2015-02-02 10:00:50 -0500
Branch: REL9_2_STABLE Release: REL9_2_10 [d95ebe0ac] 2015-02-02 10:00:51 -0500
Branch: REL9_1_STABLE Release: REL9_1_15 [11f738a8a] 2015-02-02 10:00:51 -0500
Branch: REL9_0_STABLE Release: REL9_0_19 [ce6f261cd] 2015-02-02 10:00:52 -0500
   Fix buffer overrun after incomplete read in pullf_read_max().
   Most callers pass a stack buffer.  The ensuing stack smash can crash the   server, and we have not ruled out the
viabilityof attacks that lead to   privilege escalation.  Back-patch to 9.0 (all supported versions).
 
   Marko Tiikkaja
   Security: CVE-2015-0243

Author: Tom Lane <tgl@sss.pgh.pa.us>Branch: master [a59ee8819]
2015-01-30 13:05:30 -0500
Branch: REL9_4_STABLE Release: REL9_4_1 [70da7aeba] 2015-01-30 13:04:59 -0500
Branch: REL9_3_STABLE Release: REL9_3_6 [f08cf8ad9] 2015-01-30 13:05:01 -0500
Branch: REL9_2_STABLE Release: REL9_2_10 [a97dfdfd9] 2015-01-30 13:05:04 -0500
Branch: REL9_1_STABLE Release: REL9_1_15 [8f51c432c] 2015-01-30 13:05:07 -0500
Branch: REL9_0_STABLE Release: REL9_0_19 [7c41a32b3] 2015-01-30 13:05:09 -0500
   Fix Coverity warning about contrib/pgcrypto's mdc_finish().
   Coverity points out that mdc_finish returns a pointer to a local buffer   (which of course is gone as soon as the
functionreturns), leaving open   a risk of misbehaviors possibly as bad as a stack overwrite.
 
   In reality, the only possible call site is in process_data_packets()   which does not examine the returned pointer
atall.  So there's no   live bug, but nonetheless the code is confusing and risky.  Refactor   to avoid the issue by
lettingprocess_data_packets() call mdc_finish()   directly instead of going through the pullf_read() API.
 
   Although this is only cosmetic, it seems good to back-patch so that   the logic in pgp-decrypt.c stays in sync
acrossall branches.
 
   Marko Kreen

Author: Tom Lane <tgl@sss.pgh.pa.us>
Branch: master [586dd5d6a] 2015-01-24 13:05:42 -0500
Branch: REL9_4_STABLE Release: REL9_4_1 [d51d4ff31] 2015-01-24 13:05:45 -0500
Branch: REL9_3_STABLE Release: REL9_3_6 [7240f9200] 2015-01-24 13:05:49 -0500
Branch: REL9_2_STABLE Release: REL9_2_10 [502e5f9c3] 2015-01-24 13:05:53 -0500
Branch: REL9_1_STABLE Release: REL9_1_15 [b00a08859] 2015-01-24 13:05:56 -0500
Branch: REL9_0_STABLE Release: REL9_0_19 [3a3ee655c] 2015-01-24 13:05:58 -0500
   Replace a bunch more uses of strncpy() with safer coding.
   strncpy() has a well-deserved reputation for being unsafe, so make an   effort to get rid of nearly all occurrences
inHEAD.
 
   A large fraction of the remaining uses were passing length less than or   equal to the known strlen() of the source,
inwhich case no null-padding   can occur and the behavior is equivalent to memcpy(), though doubtless   slower and
certainlyharder to reason about.  So just use memcpy() in   these cases.
 
   In other cases, use either StrNCpy() or strlcpy() as appropriate (depending   on whether padding to the full length
ofthe destination buffer seems   useful).
 
   I left a few strncpy() calls alone in the src/timezone/ code, to keep it   in sync with upstream (the IANA tzcode
distribution). There are also a   few such calls in ecpg that could possibly do with more analysis.
 
   AFAICT, none of these changes are more than cosmetic, except for the four   occurrences in fe-secure-openssl.c,
whichare in fact buggy: an overlength   source leads to a non-null-terminated destination buffer and ensuing
misbehavior. These don't seem like security issues, first because no stack   clobber is possible and second because if
yourvalues of sslcert etc are   coming from untrusted sources then you've got problems way worse than this.   Still,
it'sundesirable to have unpredictable behavior for overlength   inputs, so back-patch those four changes to all active
branches.

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company