Re: [BUGS] Server crash while trying to read expression using pg_get_expr()

(moving to pgsql-hackers)

On 03/06/10 10:37, Heikki Linnakangas wrote:
> However, I'm afraid we're lacking in input validation of read-funcs in
> general. ...
 >
> Does anyone have an idea on how
> to validate the input in a more wholesale fashion, so that we don't need
> to plug these holes one by one?

Apparently not :-(.

We have two options:

1. Make pg_get_expr() handle arbitrary (possibly even malicious) input
gracefully.

2. Restrict pg_get_expr() to superusers only.

Does anyone want to argue for option 2? We could create views using
pg_get_expr() over the internal catalogs that store trees, so that
regular users could access those without being able to pass arbitrary
input to pg_get_expr(). However, it would break existing applications,
at least pgAdmin uses pg_get_expr().

Assuming we want to make pg_get_expr() check its input, we need to:

* plug the hole Rushabh reported, and not crash on premature end of string
* check all Node types, so that you e.g. can't pass an Integer in a
field that's supposed to hold a CaseWhenExpr
* similarly, check that all Lists contain elements of the right type.

This can all be done in a straightforward way in readfuncs.c, we just
need a bit more decoration to all the READ_* macros. However, that's
still not enough; the functions in ruleutils.c make a number of other
assumptions, like that an OpExpr always has exactly one or two
arguments. That kind of assumptions will need to be explicitly checked.
Many of them already have Asserts, they need to be turned into elogs.

Thoughts? Attached is a patch for the readfuncs.c changes. Unless
someone has a better idea, I'll start going through ruleutils.c and add
explicit checks for any unsafe assumptions. It's going to be a lot of
work, as there's a lot of code in ruleutils.c and the changes need to be
backpatched as well.

--
   Heikki Linnakangas
   EnterpriseDB   http://www.enterprisedb.com