SQL Injection Issue Discovered in 1.2.x, hotfix available.

[Chris Travers <..hidden..>]

Hi all;

A minor sql injection issue has been discovered in 1.2.x which is not
believed to be exploitable.  This email describes the issue, the
threat assessment (why we conclude it is not a threat) as well as the
rationale for providing a hotfix.  Due to the nature of this issue it
is not expected to pose security problems and no security advisory is
planned unless someone can show a plausible exploit  at present.  I am
convinced that no such exploit exists at present.

The custom fields management routines improperly escaped table and
field names, allowing for sql injection in the arguments of these
routines.  These routines execute data manipulation language
statements against the database, altering the tables which store
custom fields.  They are not exposed to the user interface of the
application and are intended for consultants to use when providing
customizations against the software.  Typically these are run from a
general-purpose database administration program (like pgAdmin) or
console (like psql).  The routines run with the permissions of whoever
invokes them so they pose no privilege escalation issues.  Because
they are run from a general purpose administration tool, it is
possible for the person who runs these to execute arbitrary SQL
without resorting to an exploit.  Because they are not exposed to the
application, there are no currently supported environments which
suppose that one is only able to run these routines.

In this specific case, there are no specific exploits against this
code which allow someone to do things they could not do by just
issuing normal SQL statements.  Therefore this is not believed to pose
a security problem at present.

I have however decided to commit a fix, and there are two reasons for doing so.

The first is just that bad use cases cause problems with the current
API.  Any time the API behaves unpredictably there is a potential for
problems.  It is better to support to some extent braindead
customizations (using single and double quotes in custom field names,
for example) than to declare those as unsupported.  It also might
increase the exposure to social engineering attacks.

The second is that a non-exploitable problem today can possibly lead
to exploitable problems tomorrow.  People may read the code in
question and emulate the errors in it, or they may code applications
against that API which would then have relevant vulnerabilities.  A
hotfix is available currently in most recent SVN.  The file is
sql/fixes/new_custom_fields_funcs.sql.

This is not a critical fix.  The number of active installations that
this should affect is exactly zero at present, barring unusual
extensions to the software.  However for those interested in the fix,
the hotfix is available.  For those who are coding sql routines,
please be aware these problems can exist, and therefore make sure you
properly use quote_literal and quote_ident in your stored procedures.

Best Wishes,
Chris Travers