Re: Potential vuln in example for "F.25.1.1. digest()"

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: "David G(dot) Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com>
Cc: "cc(at)sse-ag(dot)ch" <cc(at)sse-ag(dot)ch>, "pgsql-docs(at)lists(dot)postgresql(dot)org" <pgsql-docs(at)lists(dot)postgresql(dot)org>
Subject: Re: Potential vuln in example for "F.25.1.1. digest()"
Date: 2021-08-17 18:33:17
Message-ID: 1368591.1629225197@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-docs

"David G. Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com> writes:
> On Tuesday, August 17, 2021, PG Doc comments form <noreply(at)postgresql(dot)org>
> 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_Your_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

In response to

Browse pgsql-docs by date

  From Date Subject
Next Message PG Doc comments form 2021-08-17 22:32:42 Unclear\mistakable description of UPDATE behaviour in "13.2.1. Read Committed Isolation Level"
Previous Message David G. Johnston 2021-08-17 18:06:34 Re: Potential vuln in example for "F.25.1.1. digest()"