Обсуждение: question about security hole CVE-2006-2313 and UTF-8

I have been experimenting with the exploit described in
http://www.postgresql.org/docs/techdocs.50 to see if our databases
are affected.

Server is 8.1.3, database encoding UTF8.
Client is a C program compiled and linked against libpq version 8.1.3
that uses UTF8 encoding.

I sent the following query:

od -c bad.sql
0000000   S   E   L   E   C   T       '   h   a   r   m   l   e   s   s
0000020 303   '   '   ,       c   u   r   r   e   n   t   _   d   a   t
0000040   e       a   s       m   a   l   i   c   i   o   u   s   ,
0000060   0       a   s       d   e   c   o   y 303   '
0000074

but the server treats the sequence of 0xC3 (octal 303) and 0x27
(apostrophe)
as two different characters.

If I change the 0x27 after the 0xC3 to 0xA4 in both cases, the resulting
sequence is correctly treated as a single character (German umlaut a).

The question: Since neither the apostrophe nor the backslash can be
a valid second byte of an UTF-8 sequence, how is it possible to
inject code by exploiting an application that escapes quotes in strings
and then uses them in queries sent to the server?

It seems to me that UTF-8 databases are safe.

Yours,
Laurenz Albe

"Albe Laurenz" <all@adv.magwien.gv.at> writes:
> It seems to me that UTF-8 databases are safe.

IIRC we determined that using UTF8 *on both the client and server sides*
is safe.  You can get burnt with combinations such as server_encoding =
UTF8 and client_encoding = SJIS (exposing PQescapeString's naivete),
or with client_encoding = UTF8 and server_encoding = anything else
(exposing the server's weak validity checking during conversion).
        regards, tom lane