Thread: patch for ECPG (BUG #2956: ECPG does not treat multibyte characters correctly.)

Hello

I found bug in ecpg concerning processing of the multi-byte character-code.
I reported as bug#2956 before.

The problem is that ecpg is NOT aware of multibyte character

If the multibyte character-code includes 0xc5('\' in ASCII),
ecpg escapes 0xc5 by mistake.
I found this problem when the client-encoding is set to SJIS,
that is one of the Japanese character set.
In SJIS, some characters have 0xc5 as the second byte.

Attached is the patch to fix this problem.

Patch replaces the original character string escape routine
of ecpg with that of libpq.

Regards,

On Fri, Feb 09, 2007 at 05:29:21PM +0900, 原田登志 wrote:
> I found bug in ecpg concerning processing of the multi-byte character-code.
> I reported as bug#2956 before.

Thanks for report and patch.

> Attached is the patch to fix this problem.

This patch is against 8.1, right? I had to apply it manually to HEAD, so
I might have made some error here.

Also I don't see why we have to add the connection to all thos function
calls, just to make sure we get an error message logged in the
connection struct that apparently isn't evaluated anyway. Please correct
me if I'm wrong on this one.

I'm just committing the changes to CVS but only to HEAD because I cannot
check if my changes broke something. The sources work fine on my system
and the regression tests pass without a problem. But then I do not have
a setup similar to yours. Could you please test this?

Michael
--
Michael Meskes
Email: Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org)
ICQ: 179140304, AIM/Yahoo: michaelmeskes, Jabber: meskes@jabber.org
Go SF 49ers! Go Rhein Fire! Use Debian GNU/Linux! Use PostgreSQL!

Michael Meskes <meskes@postgresql.org> wrote:

> > I found bug in ecpg concerning processing of the multi-byte character-code.
> > I reported as bug#2956 before.
>
> I'm just committing the changes to CVS but only to HEAD because I cannot
> check if my changes broke something. The sources work fine on my system
> and the regression tests pass without a problem. But then I do not have
> a setup similar to yours. Could you please test this?

I tested the change and it worked fine, but I found that this fix
should be backported -- it might cause SQL injections depending on
the server configurations.

The attached patches are backports for the past releases.
I hope you will apply them. Thanks.


[TEST]
1. initdb --no-locale --encoding=UTF8
2. SET client_encoding = sjis in postgresql.conf
3. ecpg test.pgc
4. gcc test.c
5. test < src.sjis.txt

[RESULTS]
The first charactor is a Japanese kanji. (0x95+0x5c)

-- 8.3dev
表'; SELECT 9999;--

-- 8.2.3 : backslash_quote = safe_encoding
sql error 'unsafe use of \' in a string literal' in line 21.

-- 8.2.3 : backslash_quote = on  (SQL injection!)
9999

-- 8.2.3 with patch : backslash_quote = safe_encoding
表'; SELECT 9999;--


Regards,
---
ITAGAKI Takahiro
NTT Open Source Software Center

On Tue, Feb 27, 2007 at 08:51:36PM +0900, ITAGAKI Takahiro wrote:
> I tested the change and it worked fine, but I found that this fix

Good to hear.

> should be backported -- it might cause SQL injections depending on

I absolutely agree, that's why I just committed your patches. :-)

Thanks for your effort.

Michael
--
Michael Meskes
Email: Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org)
ICQ: 179140304, AIM/Yahoo: michaelmeskes, Jabber: meskes@jabber.org
Go SF 49ers! Go Rhein Fire! Use Debian GNU/Linux! Use PostgreSQL!