Re: possible design bug with PQescapeString()

From: Tatsuo Ishii <ishii(at)sraoss(dot)co(dot)jp>
To: andrew(at)supernews(dot)com, andrew+nonews(at)supernews(dot)com
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: possible design bug with PQescapeString()
Date: 2006-02-26 22:31:35
Message-ID: 20060227.073135.32720485.t-ishii@sraoss.co.jp
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

> On 2006-02-26, Tatsuo Ishii <ishii(at)sraoss(dot)co(dot)jp> wrote:
> >> On 2006-02-20, Tatsuo Ishii <ishii(at)sraoss(dot)co(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Luke Lonergan 2006-02-26 23:01:19 Re: TOAST compression
Previous Message Stephan Szabo 2006-02-26 22:09:07 Re: constraints and sql92 information_schema compliance