Re: a vulnerability in PostgreSQL

Поиск
Список
Период
Сортировка
От Lincoln Yeoh
Тема Re: a vulnerability in PostgreSQL
Дата
Msg-id 5.1.0.14.1.20020502163708.035fc620@192.228.128.13
обсуждение исходный текст
Ответ на a vulnerability in PostgreSQL  (Tatsuo Ishii <t-ishii@sra.co.jp>)
Ответы Re: a vulnerability in PostgreSQL  (Tatsuo Ishii <t-ishii@sra.co.jp>)
Список 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 по дате отправления:

Предыдущее
От: Tatsuo Ishii
Дата:
Сообщение: a vulnerability in PostgreSQL
Следующее
От: Lincoln Yeoh
Дата:
Сообщение: Re: Search from newer tuples first, vs older tuples first?