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&amp;dt=2015-04-23%2004%3A20%3A00
http://www.pgbuildfarm.org/cgi-bin/show_log.pl?nm=leech&amp;dt=2015-04-23%2003%3A47%3A14
http://www.pgbuildfarm.org/cgi-bin/show_log.pl?nm=markhor&amp;dt=2015-04-23%2000%3A00%3A12
http://www.pgbuildfarm.org/cgi-bin/show_log.pl?nm=jaguarundi&amp;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 identified the 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 to 9.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 viability of 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 function returns), 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 at all. So there's no
live bug, but nonetheless the code is confusing and risky. Refactor
to avoid the issue by letting process_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 across all 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 in HEAD.

A large fraction of the remaining uses were passing length less than or
equal to the known strlen() of the source, in which case no null-padding
can occur and the behavior is equivalent to memcpy(), though doubtless
slower and certainly harder 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 of the 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, which are 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 your values of sslcert etc are
coming from untrusted sources then you've got problems way worse than this.
Still, it's undesirable 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

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Robert Haas wrote:

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

Yeah, I think the buildfarm script is failing to save the error log.
Anyway AFAIR this is related to the move from contrib to src/bin;
machines that have updated to buildfarm 4.15 work fine, those that are
on older versions report failure.

--
�lvaro Herrera http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Robert Haas <robertmhaas@gmail.com> writes:

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. :-(

Given that anole is the only one reporting this, I'm not sure that we
should immediately blame Postgres itself. I have a vague recollection
that we've seen this symptom before and traced it to a bug in some
supporting library. Is anole using any particularly out-of-date versions
of openssl, kerberos, etc?

regards, tom lane

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

I wrote:

Given that anole is the only one reporting this, I'm not sure that we
should immediately blame Postgres itself. I have a vague recollection
that we've seen this symptom before and traced it to a bug in some
supporting library. Is anole using any particularly out-of-date versions
of openssl, kerberos, etc?

A bit of digging in the archives suggests that my hindbrain remembered this:
/messages/by-id/4F5A8404.8020708@dunslane.net

The specifics probably don't apply to anole, but the conclusion that
inconsistent openssl header and library files triggered the bug might.

Maybe it'd be worth trying to see if we could detect such inconsistencies
during configure?

regards, tom lane

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Robert,

On Thursday, April 23, 2015, Robert Haas <robertmhaas@gmail.com> wrote:

On Thu, Apr 23, 2015 at 6:13 AM, Sandeep Thakkar
<sandeep.thakkar@enterprisedb.com <javascript:;>> 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:

Interesting. I'll take a deeper look at what's going on there tonight.

Thanks!

Stephen

On Thu, Apr 23, 2015 at 10:54:45AM -0400, Tom Lane wrote:

I wrote:

Given that anole is the only one reporting this, I'm not sure that we
should immediately blame Postgres itself. I have a vague recollection
that we've seen this symptom before and traced it to a bug in some
supporting library. Is anole using any particularly out-of-date versions
of openssl, kerberos, etc?

A bit of digging in the archives suggests that my hindbrain remembered this:
/messages/by-id/4F5A8404.8020708@dunslane.net

The specifics probably don't apply to anole, but the conclusion that
inconsistent openssl header and library files triggered the bug might.

A library problem is plausible. anole builds without OpenSSL, and I have no
guess for which remaining library could be at fault. I could not reproduce
this in an HP-UX IA-64 build configured as follows (no HP compiler available):
./configure --enable-debug --enable-cassert --enable-depend --without-readline --without-zlib CC='gcc -pthread -mlp64'

Sandeep, I suggest trying a build at commit 36e5247, the last REL9_4_STABLE
commit known good on anole. If that build fails, you'll know there's an
environmental problem, like a broken dependency library. If that build
succeeds, please use "git bisect" to find which commit broke things, and
report the commit hash here.

Thanks,
nm

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Hi Noah

The build at commit 36e5247 also failed. With new buildfarm client 4.15, we
used additional configure options like --with-gssapi -with-libxml
--with-libxml --with-ldap --with-libxslt . The build at commit 36e5247 and
last commit is successful without these options. I'll check which of these
libs is causing an issue and if updating it resolves it.

Thanks.

On Fri, Apr 24, 2015 at 7:55 AM, Noah Misch <noah@leadboat.com> wrote:

On Thu, Apr 23, 2015 at 10:54:45AM -0400, Tom Lane wrote:

I wrote:

Given that anole is the only one reporting this, I'm not sure that we
should immediately blame Postgres itself. I have a vague recollection
that we've seen this symptom before and traced it to a bug in some
supporting library. Is anole using any particularly out-of-date

versions

of openssl, kerberos, etc?

A bit of digging in the archives suggests that my hindbrain remembered

this:

/messages/by-id/4F5A8404.8020708@dunslane.net

The specifics probably don't apply to anole, but the conclusion that
inconsistent openssl header and library files triggered the bug might.

A library problem is plausible. anole builds without OpenSSL, and I have
no
guess for which remaining library could be at fault. I could not reproduce
this in an HP-UX IA-64 build configured as follows (no HP compiler
available):
./configure --enable-debug --enable-cassert --enable-depend
--without-readline --without-zlib CC='gcc -pthread -mlp64'

Sandeep, I suggest trying a build at commit 36e5247, the last REL9_4_STABLE
commit known good on anole. If that build fails, you'll know there's an
environmental problem, like a broken dependency library. If that build
succeeds, please use "git bisect" to find which commit broke things, and
report the commit hash here.

Thanks,
nm

--
Sandeep Thakkar