FYI
I have sent an email to cores to ask if I am OK to bring another but
closely related to this issue to open discussions, whose details have
already been sent to them. The reason why I'm asking is, if this issue
could be open, then the issue might be open too and that makes
discussions easier.
Tatsuo Ishii <[EMAIL PROTECTED]> writes:
> 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.
Considering that you've already described the problem on pgs
> On 2006-02-26, Tatsuo Ishii <[EMAIL PROTECTED]> wrote:
> >> On 2006-02-20, Tatsuo Ishii <[EMAIL PROTECTED]> 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
On 2006-02-26, Tatsuo Ishii <[EMAIL PROTECTED]> wrote:
>> On 2006-02-20, Tatsuo Ishii <[EMAIL PROTECTED]> 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
> > > > > Sound good to pass PGconn to new-PQescapeString. Here is the
> > > > > proposed calling sequence for the new function:
> > > > >
> > > > > size_t PQescapeStringWithConn (const PGconn *conn, char
> > > *to, const
> > > > > char *from, size_t length)
> > > > >
> > > > > If this is ok, I
> > > > > But actually I'd argue that
> > > > > letting the client programmer supply the encoding is still a
> > > > > pretty dangerous practice. Your example demonstrates
> > that if the
> > > > > encoding PQescapeString is told is different from the
> > encoding the
> > > > > backend parser
> > > > But actually I'd argue that
> > > > letting the client programmer supply the encoding is still a
> > > > pretty dangerous practice. Your example demonstrates
> that if the
> > > > encoding PQescapeString is told is different from the
> encoding the
> > > > backend parser thinks is in
> > > But actually I'd argue that
> > > letting the client programmer supply the encoding is still a pretty
> > > dangerous practice. Your example demonstrates that if the encoding
> > > PQescapeString is told is different from the encoding the backend parser
> > > thinks is in use, problems resul
> On 2006-02-20, Tatsuo Ishii <[EMAIL PROTECTED]> 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.
--
Tatsuo Ishii
SRA OSS, Inc. Japan
---(end of broadcast)
On 2006-02-20, Tatsuo Ishii <[EMAIL PROTECTED]> wrote:
> In further investigation, Akio Ishida found this kind of attack is
> possible even with EUC_JP/UTF-8.
How?
--
Andrew, Supernews
http://www.supernews.com - individual and corporate NNTP services
---(end of broadcast
> > Tatsuo Ishii <[EMAIL PROTECTED]> writes:
> > > I suggest that PQescapeString() should have a parameter to specify the
> > > encoding of "to".
> >
> > You mean the encoding of "from", no?
>
> Oops, "from", yes.
>
> > But actually I'd argue that
> > letting the client programmer supply the enc
On Sun, Feb 19, 2006 at 12:13:48PM -0500, Tom Lane wrote:
> Florian Weimer <[EMAIL PROTECTED]> writes:
> > Uh-oh, this is my fault. PQescapeString should escape all characters
> > greater than 126.
>
> No, that doesn't work, because the de-escaping on the backend side
> happens *after* conversion
Florian Weimer <[EMAIL PROTECTED]> writes:
> Uh-oh, this is my fault. PQescapeString should escape all characters
> greater than 126.
No, that doesn't work, because the de-escaping on the backend side
happens *after* conversion to the backend encoding. If you insert escapes
into the middle of mu
> >> Uh-oh, this is my fault. PQescapeString should escape all characters
> >> greater than 126. Unfortunately, there is nothing we can do about
> >> this in the current function because tha twould need four times the
> >> lenggth of the input string (plus one). Drat.
> >
> > Please don't do tha
* Tatsuo Ishii:
>> Uh-oh, this is my fault. PQescapeString should escape all characters
>> greater than 126. Unfortunately, there is nothing we can do about
>> this in the current function because tha twould need four times the
>> lenggth of the input string (plus one). Drat.
>
> Please don't d
> * Tatsuo Ishii:
>
> > Users can input value for "var" from a web form. The attacker inputs
> > following string:
> >
> > (0x95+0x27);DELETE FROM members;--
> >
> > where 0x95+0x27 is actually a SJIS mutibyte KANJI. Programmer applies
> > PQescapeString() to it and gets:
> >
> > 0x95+0x27+0x27;DE
* Tatsuo Ishii:
> Users can input value for "var" from a web form. The attacker inputs
> following string:
>
> (0x95+0x27);DELETE FROM members;--
>
> where 0x95+0x27 is actually a SJIS mutibyte KANJI. Programmer applies
> PQescapeString() to it and gets:
>
> 0x95+0x27+0x27;DELETE FROM members;--
> Tatsuo Ishii <[EMAIL PROTECTED]> writes:
> > I suggest that PQescapeString() should have a parameter to specify the
> > encoding of "to".
>
> You mean the encoding of "from", no?
Oops, "from", yes.
> But actually I'd argue that
> letting the client programmer supply the encoding is still a pre
Tatsuo Ishii <[EMAIL PROTECTED]> writes:
> I suggest that PQescapeString() should have a parameter to specify the
> encoding of "to".
You mean the encoding of "from", no? But actually I'd argue that
letting the client programmer supply the encoding is still a pretty
dangerous practice. Your exam
I believe PQescapeString() has an important design bug and it casues a
security risk.
The function's signature is:
size_t PQescapeString (char *to, const char *from, size_t length);
As you might notice, it's impossible to specify encoding of "to". As a
result, it turns every occurrences of 0x
20 matches
Mail list logo
