Re: a vulnerability in PostgreSQL - Mailing list pgsql-hackers

From Lincoln Yeoh
Subject Re: a vulnerability in PostgreSQL
Date
Msg-id 5.1.0.14.1.20020502163708.035fc620@192.228.128.13
Whole thread Raw
In response to a vulnerability in PostgreSQL  (Tatsuo Ishii <t-ishii@sra.co.jp>)
Responses Re: a vulnerability in PostgreSQL  (Tatsuo Ishii <t-ishii@sra.co.jp>)
List pgsql-hackers
Not tested: but how about the string being
foo'; DROP TABLE T1; foo

Would the last ' be eaten up then resulting in no error?

Also normally a \ would be quoted by \\ right? Would a foo\ result in an 
unquoted \ ? An unquoted backslash may allow some possibilities.

There could be other ways to get rid of the last ', comments etc, so it may 
not be just 6.5.x.

Regards,
Link.

At 05:18 PM 5/2/02 +0900, Tatsuo Ishii wrote:
>There is a report from a debian user about a vulnerability in
>PostgreSQL pre 7.2. Here is a possible attack scenario which allows to
>execute ANY SQL in PostgreSQL.
>
>A web application accepts an input as a part of SELECT qualification
>clause. With the user input, the web server program would build a
>query for example:
>
>SELECT * FROM t1 WHERE foo = 'input_string_from_user'
>
>Of course above method is too simple, since a user could input a
>string such as:
>
>foo'; DROP TABLE t1
>
>To prevent the unwanted SQL statement being executed, the usual method
>most applications are taking is quoting ' by \. With this, above
>string would be turned into:
>
>foo\'; DROP TABLE t1
>
>which would make it impossible to execute the DROP TABLE statement.
>For example in PHP, addslashes() function does the job.
>
>Now, suppose the database encoding is set to SQL_ASCII and the client
>encoding is, say, LATIN1 and "foo" in above string is a latin
>character which cannot be converted to ASCII. In this case, PostgreSQL
>would produce something like:
>
>(0x81a2)\'; DROP TABLE t1
>
>Unfortunately there was a bug in pre 7.2's multibyte support that
>would eat the next character after the
>impossible-to-convert-character, and would produce:
>
>(0x81a2)'; DROP TABLE t1
>
>(notice that \ before ' is disappeared)




pgsql-hackers by date:

Previous
From: Tatsuo Ishii
Date:
Subject: a vulnerability in PostgreSQL
Next
From: Lincoln Yeoh
Date:
Subject: Re: Search from newer tuples first, vs older tuples first?