Re: Need help with quote escaping in exim for postgresql - Mailing list pgsql-general

On Fri, Jul 07, 2006 at 04:53:14PM +0200, Martijn van Oosterhout wrote:
> On Fri, Jul 07, 2006 at 03:48:00PM +0200, Marc Haber wrote:
> > I am the maintainer of Debian's packages for exim4, a powerful and
> > versatile Mail Transfer Agent developed in Cambridge and in wide use
> > throughout the Free Software Community (http://www.exim.org/).
> >
> > One of our daemon flavours has PostgreSQL support. Our security guys
> > have found a flaw in exim regarding quote escaping for PostgreSQL. The
> > bug is filed in Debian's BTS as http://bugs.debian.org/369351 and was
> > transferred to exim's Bugzilla installation as
> > http://www.exim.org/bugzilla/show_bug.cgi?id=107.
>
> Whether or not the quick fix works for you depends entirly on the
> encoding used by the client to talk to the database.

I am afraid that we don't have any information about the encoding used
since exim allows arbitrary SQL commands to be given in the run-time
configuration file.

>     * If application always sends untrusted strings as out-of-line
> parameters, instead of embedding them into SQL commands, it is not
> vulnerable.

exim's configuration holds SQL string literals like
|server_condition = "${if and { \
|                      {!eq{$2}{}} \
|                      {!eq{$3}{}} \
|                      {crypteq{$3}{${lookup mysql{SELECT password FROM customers WHERE ( domain_name = \
|                '${domain:$2}' \
|                AND local_part = '${local_part:$2}') OR user_id='$2'}{$value}fail}} }} {yes}{no}}"
(which is code helping exim to do SMTP AUTH against a password
database stored in mysql. Using PostgreSQL is very similiar, so you'll
get the idea - taken from
http://www.exim.org/eximwiki/AuthenticatedSmtpUsingMysql).

>     * If client_encoding is a single-byte encoding (e.g., one of the
> LATINx family), there is no vulnerability.

From what I can see, exim configuration does not allow an encoding to
be set fot the communication with pgsql, and the code does not match
on "client_encoding". Am I right to assume that without special
handling, anything passed to it from the configuration is passed on
verbatim to the pgsql server?

>     * If application cannot pass invalidly encoded data to the server,
> there is no vulnerability (this probably includes all Java
> applications, for example, because of Java's handling of Unicode
> strings).

I am afraid that it is quite easy to (mis)configure exim so that it is
possible to pass invalidly encoded data.

> The easiest may be to simply always set the client encoding to
> something like UTF-8 and work the escaping rules so they work with
> that.

If that's possible, it might. We'd need to know how our input data is
encoded and recode to UTF-8, right?

Greetings
Marc

--
-----------------------------------------------------------------------------
Marc Haber         | "I don't trust Computers. They | Mailadresse im Header
Mannheim, Germany  |  lose things."    Winona Ryder | Fon: *49 621 72739834
Nordisch by Nature |  How to make an American Quilt | Fax: *49 621 72739835