Re: pg_cryptohash_final possible out-of-bounds access (per Coverity) - Mailing list pgsql-hackers

From Michael Paquier
Subject Re: pg_cryptohash_final possible out-of-bounds access (per Coverity)
Date
Msg-id YCkH2/hpnj+QXIHQ@paquier.xyz
Whole thread Raw
In response to Re: pg_cryptohash_final possible out-of-bounds access (per Coverity)  (Ranier Vilela <ranier.vf@gmail.com>)
Responses Re: pg_cryptohash_final possible out-of-bounds access (per Coverity)
List pgsql-hackers
On Sat, Feb 13, 2021 at 09:33:48PM -0300, Ranier Vilela wrote:
> Em sáb., 13 de fev. de 2021 às 20:32, Michael Paquier <michael@paquier.xyz>
> escreveu:
>
>> You are missing the point here.  What you are proposing here would not
>> be backpatched.  However, reusing the same words as upthread, this has
>> a cost in terms of *future* maintenance.  In short, any *future*
>> potential bug fix that would require to be backpatched in need of
>> using this function or touching its area would result in a conflict.
>
> Ok. +1 for back-patching.

Please take the time to read again my previous email.

And also, please take the time to actually test patches you send,
because the list of things getting broken is impressive.  At least
you make sure that the internals of cryptohash.c generate an error as
they should because of those incorrect sizes :)

git diff --check complains, in various places.

@@ -330,7 +330,8 @@ SendBackupManifest(backup_manifest_info *manifest)
      * twice.
      */
     manifest->still_checksumming = false;
-    if (pg_cryptohash_final(manifest->manifest_ctx, checksumbuf) < 0)
+    if (pg_cryptohash_final(manifest->manifest_ctx, checksumbuf,
+                            sizeof(checksumbuf) - 1) < 0)
         elog(ERROR, "failed to finalize checksum of backup manifest");
This breaks backup manifests, due to an incorrect calculation.

@@ -78,7 +78,8 @@ pg_md5_hash(const void *buff, size_t len, char *hexsum)
     if (pg_cryptohash_init(ctx) < 0 ||
         pg_cryptohash_update(ctx, buff, len) < 0 ||
-        pg_cryptohash_final(ctx, sum) < 0)
+        pg_cryptohash_final(ctx, sum,
+                            sizeof(sum) - 1) < 0)
This one breaks MD5 hashing, due to an incorrect size calculation,
again.

@@ -51,7 +51,8 @@ scram_HMAC_init(scram_HMAC_ctx *ctx, const uint8 *key, int keylen)
             return -1;
         if (pg_cryptohash_init(sha256_ctx) < 0 ||
             pg_cryptohash_update(sha256_ctx, key, keylen) < 0 ||
-            pg_cryptohash_final(sha256_ctx, keybuf) < 0)
+            pg_cryptohash_final(sha256_ctx, keybuf,
+                                sizeof(keybuf) - 1) < 0)
[...]
-    if (pg_cryptohash_final(ctx->sha256ctx, h) < 0)
+    if (pg_cryptohash_final(ctx->sha256ctx, h,
+                            sizeof(h) - 1) < 0)
This breaks SCRAM authentication, for the same reason.  In three
places.

I think that in pg_checksum_final() we had better save the digest
length in "retval" before calling pg_cryptohash_final(), and use it
for the size passed down.

contrib/uuid-ossp/ fails to compile.

contrib/pgcrypto/ fix is incorrect, requiring h->result_size(h) in
three places.

I think that as a whole we should try to minimize the number of times
we use any DIGEST_LENGTH variable, relying a maximum on sizeof().
This v4 is a mixed bad of that.  Once you switch to that, there is an
interesting result with uuid-ossp, where you can notice that there is
a match between the size of dce_uuid_t and MD5_DIGEST_LENGTH.

No need to send a new patch, the attached taking care of those
issues, and it is correctly indented.  I'll just look at that again
tomorrow, it is already late here.
--
Michael

Attachment

pgsql-hackers by date:

Previous
From: Etsuro Fujita
Date:
Subject: Re: Asynchronous Append on postgres_fdw nodes.
Next
From: Michael Paquier
Date:
Subject: Re: How to get Relation tuples in C function