Re: possible design bug with PQescapeString() - Mailing list pgsql-hackers

From Tatsuo Ishii
Subject Re: possible design bug with PQescapeString()
Date
Msg-id 20060227.073135.32720485.t-ishii@sraoss.co.jp
Whole thread Raw
In response to Re: possible design bug with PQescapeString()  (Andrew - Supernews <andrew+nonews@supernews.com>)
Responses Re: possible design bug with PQescapeString()
List pgsql-hackers
> On 2006-02-26, Tatsuo Ishii <ishii@sraoss.co.jp> wrote:
> >> On 2006-02-20, Tatsuo Ishii <ishii@sraoss.co.jp> wrote:
> >> > In further investigation, Akio Ishida found this kind of attack is
> >> > possible even with EUC_JP/UTF-8.
> >> 
> >> How?
> >
> > The details have been sent to cores.
> 
> I wasn't asking out of idle curiosity. Some preliminary investigation
> that I have done suggests that when using UTF-8, the proposed changes
> do not fix the problem (and may make matters worse). So I want to know
> whether the problem that I'm looking at is the same thing as the one
> you're looking at.
> 
> UTF-8 has the property that neither ' nor \ can appear as part of a
> valid multibyte sequence. But many places in postgres are extremely
> sloppy about handling _invalid_ utf-8, and unless you're prepared to
> make the escape routine fail outright in such cases (which I would
> strongly favour), it is likely that there will always be ways to get
> malformed sequences into the backend (which itself is far too lax
> about parsing them).

I guess I understand whay you are saying. However, I am not allowed to
talk to you about it unless cores allow me. Probably we need some
closed forum to discuss this kind of security issues. The forum should
be consisted with cores and people who are admitted by cores.

Cores, what do you think?
--
Tatsuo Ishii
SRA OSS, Inc. Japan


pgsql-hackers by date:

Previous
From: Stephan Szabo
Date:
Subject: Re: constraints and sql92 information_schema compliance
Next
From: "Luke Lonergan"
Date:
Subject: Re: TOAST compression