Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1mG3tr-0003z2-B3 for pgsql-docs@arkaria.postgresql.org; Tue, 17 Aug 2021 18:33:23 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1mG3tq-0001Nu-7o for pgsql-docs@arkaria.postgresql.org; Tue, 17 Aug 2021 18:33:22 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1mG3tq-0001Nl-1r for pgsql-docs@lists.postgresql.org; Tue, 17 Aug 2021 18:33:22 +0000 Received: from sss.pgh.pa.us ([66.207.139.130]) by makus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1mG3tn-0007GG-Tg for pgsql-docs@lists.postgresql.org; Tue, 17 Aug 2021 18:33:21 +0000 Received: from sss1.sss.pgh.pa.us (localhost [127.0.0.1]) by sss.pgh.pa.us (8.15.2/8.15.2) with ESMTP id 17HIXHSP1368592; Tue, 17 Aug 2021 14:33:17 -0400 From: Tom Lane To: "David G. Johnston" cc: "cc@sse-ag.ch" , "pgsql-docs@lists.postgresql.org" Subject: Re: Potential vuln in example for "F.25.1.1. digest()" In-reply-to: References: <162921671324.1653.2466671901617491685@wrigleys.postgresql.org> Comments: In-reply-to "David G. Johnston" message dated "Tue, 17 Aug 2021 11:06:34 -0700" MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <1368590.1629225197.1@sss.pgh.pa.us> Content-Transfer-Encoding: quoted-printable Date: Tue, 17 Aug 2021 14:33:17 -0400 Message-ID: <1368591.1629225197@sss.pgh.pa.us> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk "David G. Johnston" writes: > On Tuesday, August 17, 2021, PG Doc comments form > wrote: >> in "F.25.1.1. digest()" you suggest: >> = >> CREATE OR REPLACE FUNCTION sha1(bytea) returns text AS $$ >> SELECT encode(digest($1, 'sha1'), 'hex') >> $$ LANGUAGE SQL STRICT IMMUTABLE; >> = >> While this is a great example, it may expose a database app to >> vulnerabilities if the attacker succeeds in overriding the function >> sha1(...) in the app's user context (schema) > You should read this: > https://wiki.postgresql.org/wiki/A_Guide_to_CVE-2018-1058%3A_Protect_You= r_Search_Path Yeah. I can't get terribly excited about trying to make this one example unconditionally-secure; there are dozens if not hundreds of similar cases in our docs. Trying to make them all safe against insecure search paths would mostly result in unreadable examples. regards, tom lane