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)
In this case actual query sent to the backend is:
SELECT * FROM t1 WHERE foo = '(0x81a2)'; DROP TABLE t1'
The last ' will casue SQL error which prevents the DROP TABLE
statement from to be executed, except for 6.5.x. (correct me if I am
wrong)
Here are the precise conditions to trigger the scenario:
(1) the backend is PostgreSQL 6.5.x
(2) multibyte support is enabled (--enable-multibyte)
(3) the database encoding is SQL_ASCII (other encodings are not
affected by the bug).
(4) the client encoding is set to other than SQL_ASCII
I think I am responsible for this since I originally wrote the
code. Sorry for this. I'm going to make back port patches to fix the
problem for pre 7.2 versions.
--
Tatsuo Ishii
---------------------------(end of broadcast)---------------------------
TIP 3: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to [EMAIL PROTECTED] so that your
message can get through to the mailing list cleanly
