On Wed, Jun 9, 2010 at 2:04 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Robert Haas <robertmhaas@gmail.com> writes:
>> On Wed, Jun 9, 2010 at 1:34 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>>> Yes, it's not a trivial fix either. We'll have to provide functions or
>>> views that replace the current usages without letting the user insert
>>> untrusted strings.
>
>> Maybe I'm all wet here, but don't we need to come up with something we
>> can back-patch?
>
> Well, ideally yes, but if it's not actually *secure* then there's no
> point --- and I don't believe that the approach of making readfuncs.c
> secure against malicious input has the proverbial snowball's chance
> of ever being bulletproof.
I don't really see how it could be *impossible* to securely parse text
input. It's certainly possible not to crash on trivially malformed
input. Completely validating the input MIGHT cost more in performance
than we want to pay in CPU cycles, but I guess I'm not seeing why it
would be an unsolvable problem apart from that.
> [ thinks for awhile... ] I wonder whether there is any way of locking
> down pg_get_expr so that it throws an error if called with anything
> except a suitable field from one of the system catalogs. There are only
> a few usage patterns that we need to allow, no? At least in recent PG
> versions it is possible for the function to check that its input
> expression is a Var. If we had some (probably horridly ugly) way to
> obtain the rangetable entry the Var refers to, we could put code into
> pg_get_expr to barf if it's not used in a context like
> "select pg_get_expr(adbin) from pg_attrdef".
That's sort of clever... in a really ugly sort of way.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise Postgres Company