Skip site navigation (1) Skip section navigation (2)

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: (view raw, whole thread or download thread mbox)
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


pgsql-hackers by date

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

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group