[SECURITY] Overtake another account

[lommy]

Hey Roundcube-Devs,

today I experience a big security hole in Roundcube!

I was using Roundcube r2991 with Dovecot and MySQL as database backend. The following happens: My brother was logged in with his username. He is not sure if he logged out or just closed the browser after sending a mail. About half a hour later I logged into Roundcube with my username. Of cause our usernames and passwords are different. While been logged in I got a lot of "Server Error! (Not found)" messages. Because of that I reloaded the whole website in my browser (We are both using Firefox 3.5.2). And now I was logged in my brother's mailbox. I asked my brother and he visited Roundcube again. He was directly in his own mailbox (I think his browser used his old cookie where he was still logged in). Even when he logged out I was still in his mailbox. I could read all his mails in all his folders. Did not check if I could access his settings or address book.

I looked up: We both were using different session ID saved in the cookies. The Roundcube logs are empty. The Apache logs are empty, too. The database scheme is up to date. I have no idea how that could happened. So I think its a Roundcube session issue. I'm sorry that I can not give a more detailed way to reproduce this security hole.

Best regards. lommy

[lommy]

I have to mension that my brother and I were working on different maschines in the same network with the same outgoing IP.

[alec]

Can you reproduce this?

[lommy]

I tried to reproduce this issue. But I was not able to overtake another active session again. I reviewed the Roundcube session code (program/include/session.inc) but I did not find anything that could result in this issue.
Maybe this was a PHP issue and not a Roundcube one. I am running Apache 2.2 with the worker mpm, thread support and mod_php 5.2.10 on a Gentoo. But because PHP is known to be not fully threadsafe this combination can cause ugly side effects. So maybe this issue was a side effect in threaded mod_php.
Please close this ticket. If someone has a similar problem the ticket should be reopened. And if I run into this problem again I will do more debuging and post these information here.
Thanks. lommy

[lommy]

Okay, I tried a lot and now I am able to give you a test case to "clone" an active session and hence overtake a mailbox as an unprivileged user.
1) Truncate your session database table.
2) Clean your browser's cache and your cookies.
3) Visit Roundcube. In the session table there is an entry of your new session and the sess_id is the same as in your new cookie.
4) Login. Now you can see the login information in your session table (vars).
5) Now create a new row in the session table via INSERT: sess_id is a arbitrarily md5sum but has to start with the same first character than the sess_id of the session you want to "clone" (In this case the same from the session we created in step 3 and 4). The dates (created, changed) can be default values, ip is a totally random ip and vars can be empty. In vars you can put every content that is parseable by Roundcube.
6) Reload your active session in Roundcube (from 3,4). Or open a mail or wait until Roundcube checks for new messages.
7) Look into the session table! The row we created manually has the same vars content than your original session! We cloned a session!
A attacker can send 16 requests to Roundcube to create 16 different sessions in the session table. He can define the sess_id by himself in sending a sess_id via cockie and because Roundcube does not find this session in his database he will create a new database record with this sess_id. Every sess_id of the requests starts with an different first character out of [0..9a-f]. Even if you change the behavior of Roundcube to choose a new sess_id and send a new cookie when Roundcube does not find the sess_id the client send the attacker can let Roundcube create sessions until he has 16 sessions with different first characters. After that the attacker periodically checks if a valid user logs in and Roundcube overrides the vars item from the user's session into one of the 16 "honeypot" sessions. Now the attackter is logged in into a mailbox. Furthermore if the valid user logs out, the "cloned" session is still logged in.
I hope you can reproduce this issue with that detailed test case! Thanks.

[lommy]

By the way: All sessions created by Roundcube just have two blocks of an ip in the ip field of the session table (example: 75.92). Is that intended?

[alec]

What database are you using (version)? Please, enable sql_debug and attach logs/sql here. I'll try to reproduce it later.

[lommy]

I am using Roundcube with MySQL 5.1.39 and InnoDB Plugin 1.0.4. Later I will enable sql_debug and attach the logs/sql file here. Thanks.

[alec]

I'm unable to reproduce using postgres. Waiting for your sql_debug.

[lommy]

I found out that this issue does not occur when I enable sql_debug. I tried a lot but I was not able to reproduce the cloning of a session with sql_debug=true. I updated all relevant components (now: up-to-date Gentoo, Apache 2.2.13, PHP 5.2.11-pl0-gentoo, MySQL 5.1.39 with InnoDB Plugin 1.0.4, Roundcube [52bd7bf1]), but with sql_debug=false I was sometimes (perhaps 70%) able to clone a session with the test case above. I am not really sure if there are some more conditions for that test case. At the next weekend I will try to investigate that issue in detail. At the moment I am not really sure if that is a Roundcube, PHP or MySQL issue. Until that problem is solved I enable sql_debug=true. Thanks.

[lommy]

I found out that this is a bug in the mysqli driver of MDB2. It only occurs when you use the mysqli driver (db_dsnw=mysqli://..) with sql_debug=false. I think that the Roundcube queries are correct, but the mysqli driver generates wrong prepared statements or wrong parameters for the execution of these prepared statements. I searched in the MDB2 and MDB2_Driver_mysqli bug database and did not find any similar issue. Maybe this issue does only occur with the latest MySQL 5.1 servers because there were no updates of the shipped MDB2 version in the last time. Or this is a regression in the handling of prepared statements of the MySQL database. But such a regression I did not find in the MySQL bug database, too.
At the moment I am just using the mysql driver with sql_debug=false and there is definitely no cloning of active sessions with the test case above possible.
Important note: I believe that you can see that your Roundcube is affected by this issue if the "ip" field in the database of a session created by Roundcube does only contain two blocks instead of four blocks (e.g. instead of "11.22.33.44" just "11.22"; see comment above).

[alec]

Works for me with mysql-5.0.51a-3ubuntu5.4, php-5.2.4 and mysqli driver. I think we can do nothing with this.