Unvoluntary session hijacking

[bartd]

Rouncube will sometimes display messages from other user's mailboxes given the fact that both users are accessing rcm from the same ip address but independent of the time in between their sessions.

The messagelist always shows the real user's messages but the preview pane or opening the e-mail will show headers & body from another mailbox that was accessed from the same client ip address.

I've seen cases were user B logs in 3 days after user A and somehow gets old of his old session which is reused to retrieve the messages. It only happens with users who share the same ip address, ie large corporate networks using NAT.

using double_auth did not fix the issue. neither did upgrading to 0.3.1. Is REMOTE_ADDR somehow used to reuse sessions?

PHP version: 5.3.1
RCM: 0.3.1
imapd: dovecot 1.2.5 through perdition
browser: problem is independent of browser, has occured in IE7 and FF3
reproducable: yes and no, I've haven't been able to reproduce but it happens on a daily basis with a large userbase.

I do have a screenshot demonstrating the problem, but I shouldn't upload it where it's publicly viewable.

[alec]

Are you sure it's related to remote address? Did you try without perdition proxy?

[bartd]

Replying to alec:

Are you sure it's related to remote address? Did you try without perdition proxy?

yes, i'm very sure it's related to the remote address of the client, in fact it's the only constant factor.

as for the example i'm referring to, i have checked that perdition has completely terminated the connection of user A. Which was actually the case. Note that Perdition also has an idle timeout of 360 seconds and user B logged in 3 days after user A.

As far as I can tell the only way to get access to another mailbox is through the stored password in the sessions table. Also it doesn't explain why the messagelist is correct, but the previewpane/messageview isn't.

note: I have also disabled SQL caching, I don't know if it's related.

[lommy]

Just a note: I had an issue where overtaking an account was possible (#1486168), too. Those days I used the mysqli MDB2 backend to connect to a MySQL database. After changing to the mysql backend (replace mysqli:// with mysql://) everything works without problems. If you are using mysqli try to use mysql. Maybe it helps you. lommy

[bartd]

Replying to lommy:

After changing to the mysql backend (replace mysqli:// with mysql://) everything works without problems. If you are using mysqli try to use mysql.

Thanks, but I'm already using mysql instead of mysqli...

[bartd]

Still unable to reproduce, but are suspecting cached content is causing the problem. All of these users who experienced the problem are on larger corporate networks and their proxy server may be ignoring the http headers that should prevent any type of caching. The proxy server is probably caching links to individual mails as they only contain a pointer to the message id :

​http://trac.roundcube.net/browser/trunk/roundcubemail/program/js/app.js#L588

obj.href = '?_task='+this.env.task+'&_action=show&_mbox='+urlencode(this.env.mailbox)+'&_uid='+uid;

while this may not be a roundcube specific issue, maybe you can circumvent badly configured proxy server and add some randomization to this url by adding a timestamp or the user_id?

[bartd]

after diving into it a bit, it would also be this line needing randomization in the URL:

​http://trac.roundcube.net/browser/trunk/roundcubemail/program/js/app.js#L1546

var url = '&_action='+action+'&_uid='+id+'&_mbox='+urlencode(this.env.mailbox)+add_url;

[alec]

Maybe it's because we're not sending "must-revalidate" in send_modified_header()?

[bartd]

Replying to alec:

Maybe it's because we're not sending "must-revalidate" in send_modified_header()?

Ah this may be just it.. I'll try changing it to see if it has any effect on users. Adding "private" may be beneficial too.

[till]

Replying to bartd:

Replying to alec:

Maybe it's because we're not sending "must-revalidate" in send_modified_header()?

Ah this may be just it.. I'll try changing it to see if it has any effect on users. Adding "private" may be beneficial too.

+1

I'm also +1 on adding a cache buster (random hash to the URL to force it). I think Gmail is using a hash for that as well.

[alec]

Fixed in [496da6a4]. About "cache buster". It's used to prevent from caching, but we don't want to do this. We want to use messages caching and we need to make it "private".

[bartd]

already added 'private' to the Cache-Control header a few days ago. the complaints decreased enormously.. but still some users are complaining due to caches ignoring the headers.

also note that the fix may conflict with the Cache-Control header set in .htaccess if it's enabled, resulting in public and private listed at the same time.

​http://trac.roundcube.net/browser/trunk/roundcubemail/.htaccess#L39

I understand you want to use caching, but I don't see much advantage in the caching of individual messages. you would only need a 'cache buster' on the URL's that fetch particular content.

[bepi]

I have this problem also with 0.5. All user on same network + proxy.

[casper]

We have the same problem. But with users not using the same IP address. Also they do not use a proxy or caching.

It seems that these two users have received the same session_id. If it is really random, it would almost never occur. But with more people complaining, I think this must be a serious bug.

We saw this with 0.5 and it still happens after upgrading to 0.5.1.

[casper]

We've added some logging and this is a very serious bug! We added some code to log the users that log in and the session_id they are getting. I have changed the IP's to IPx and the usernames to mail-userx, with a number so you can see what the different users are.

[02-Mar-2011 12:38:21 +0100]: Successful login for mail-user1 (ID: 10) from IP1 sessionid: 9ae77c489cb156a0ba66c2f0c2892103
[02-Mar-2011 13:07:36 +0100]: Successful login for mail-user1 (ID: 10) from IP2 sessionid: 1a314117142728eaede1831942ee69fa
[02-Mar-2011 13:32:29 +0100]: Successful login for mail-user2 (ID: 23) from IP3 sessionid: 37e7a54aacfcd2a15f557b875b50654c
[02-Mar-2011 14:47:50 +0100]: Successful login for mail-user3 (ID: 112) from IP4 sessionid: 37e7a54aacfcd2a15f557b875b50654c
[02-Mar-2011 15:00:52 +0100]: Successful login for mail-user3 (ID: 112) from IP4 sessionid: 25af88364e6320ee0eef10c5b8f60012
[02-Mar-2011 15:03:41 +0100]: Successful login for mail-user4 (ID: 32) from IP5 sessionid: 37e7a54aacfcd2a15f557b875b50654c
[02-Mar-2011 15:04:08 +0100]: Successful login for mail-user5 (ID: 33) from IP5 sessionid: cb50845f543b6bb9f3d8076455c46c2d
[02-Mar-2011 15:04:13 +0100]: Successful login for mail-user3 (ID: 112) from IP4 sessionid: 584d7fcc224a07ed7662eede3582c335
[02-Mar-2011 15:17:36 +0100]: Successful login for mail-user3 (ID: 112) from IP4 sessionid: 37e7a54aacfcd2a15f557b875b50654c
[02-Mar-2011 15:23:31 +0100]: Successful login for mail-user3 (ID: 112) from IP4 sessionid: e9bbbc19ffadaa228d7d69ad6a5ce0d6

I think this has very high priority.

[casper]

We changed the rcmail_log_login() function in main.inc to get this extra logging. The changed function looks like this:

function rcmail_log_login()
{

global $RCMAIL;

if (!$RCMAIL->config->get('log_logins')

!$RCMAIL->user)

return;

write_log('userlogins', sprintf('Successful login for %s (ID: %d) from %s sessionid: %s',

$RCMAIL->user->get_username(), $RCMAIL->user->ID, rcmail_remote_ip(),session_id() ) );

}

[alec]

What PHP version? Please debug rcube_session::regenerate_id() function.

[casper]

PHP Version => 5.2.17

How can we easily debug regenerate_id() ?

[casper]

We tested the regenerate_id() extensively, but it does not generate the same ID in more than 100.000 rounds. So it seems this bug is somewhere else in the code.

[casper]

We are only logging this for a few hours now, but there are 6 different users, all got the session_id 37e7a54aacfcd2a15f557b875b50654c. There are no other ID's that are used multiple times so far.

[casper]

We extended the logging some more, it seems that the random value is not so random:

[02-Mar-2011 16:56:00 +0100]: call to regenerate_id() current_id: 9ae77c489cb156a0ba66c2f0c2892103
[02-Mar-2011 16:56:00 +0100]: random value: BgXiDZIXYzQMAHtESIjSP0Koeg1rIMOS
[02-Mar-2011 16:56:00 +0100]: random value md5: 1aeb6fac98349f521b8471a627a64c88
[02-Mar-2011 16:56:00 +0100]: Successful login for user@… (ID: 10) from IPv6address sessionid: 1aeb6fac98349f521b8471a627a64c88
[02-Mar-2011 16:56:14 +0100]: call to regenerate_id() current_id: 1aeb6fac98349f521b8471a627a64c88
[02-Mar-2011 16:56:14 +0100]: random value: zCLIWjorsK3duMPymSQiDbvzZrzlZuGV
[02-Mar-2011 16:56:14 +0100]: random value md5: 37e7a54aacfcd2a15f557b875b50654c
[02-Mar-2011 16:56:14 +0100]: Successful login for user@… (ID: 10) from IPv6address sessionid: 37e7a54aacfcd2a15f557b875b50654c
[02-Mar-2011 17:00:43 +0100]: call to regenerate_id() current_id: 37e7a54aacfcd2a15f557b875b50654c
[02-Mar-2011 17:00:43 +0100]: random value: E1DYSoMDZTJEKplShBbJGIBdYLxO9del
[02-Mar-2011 17:00:43 +0100]: random value md5: 3f8b7940444daab0a9e4b8111d5e6149
[02-Mar-2011 17:00:43 +0100]: Successful login for user@… (ID: 10) from IPv6address sessionid: 3f8b7940444daab0a9e4b8111d5e6149
[02-Mar-2011 17:00:48 +0100]: call to regenerate_id() current_id: 3f8b7940444daab0a9e4b8111d5e6149
[02-Mar-2011 17:00:48 +0100]: random value: 8HsJq3iraGBdYP92KcVJ4ZnWHHsDUMLH
[02-Mar-2011 17:00:48 +0100]: random value md5: 0bcf45d6a24ab3c508ea8df332bff9c4
[02-Mar-2011 17:00:48 +0100]: Successful login for user@… (ID: 10) from IPv6address sessionid: 0bcf45d6a24ab3c508ea8df332bff9c4
[02-Mar-2011 17:00:57 +0100]: call to regenerate_id() current_id: 0bcf45d6a24ab3c508ea8df332bff9c4
[02-Mar-2011 17:00:57 +0100]: random value: inkY3VazzC7ztWg4kmdOhlffxr49pAjI
[02-Mar-2011 17:00:57 +0100]: random value md5: 382ce9c812d262df47d6277d88bf639f
[02-Mar-2011 17:00:57 +0100]: Successful login for user@… (ID: 10) from IPv6address sessionid: 382ce9c812d262df47d6277d88bf639f
[02-Mar-2011 17:01:01 +0100]: call to regenerate_id() current_id: 382ce9c812d262df47d6277d88bf639f
[02-Mar-2011 17:01:01 +0100]: random value: IWjorsK3duMPymSQiDbvzZrzlZuGVFKx
[02-Mar-2011 17:01:01 +0100]: random value md5: dff9f8bbe1caa9e7e58ec5970e14bee5
[02-Mar-2011 17:01:01 +0100]: Successful login for user@… (ID: 10) from IPv6address sessionid: dff9f8bbe1caa9e7e58ec5970e14bee5
[02-Mar-2011 17:01:10 +0100]: call to regenerate_id() current_id: dff9f8bbe1caa9e7e58ec5970e14bee5
[02-Mar-2011 17:01:10 +0100]: random value: zCLIWjorsK3duMPymSQiDbvzZrzlZuGV
[02-Mar-2011 17:01:10 +0100]: random value md5: 37e7a54aacfcd2a15f557b875b50654c
[02-Mar-2011 17:01:10 +0100]: Successful login for user@… (ID: 10) from IPv6address sessionid: 37e7a54aacfcd2a15f557b875b50654c

The random function gives multiple times zCLIWjorsK3duMPymSQiDbvzZrzlZuGV as a 'random' string.

[casper]

Oke, we found it.

In the file rcube_session.php in the function regenerate_id()

change this: $random .= substr($randval, mt_rand(0,(strlen($randval) - 1)), 1);

to this: $random .= substr($randval, rand(0,(strlen($randval) - 1)), 1);

And the problem is solved. With the mt_rand() function, we get the same ID in 25% of the cases. With the rand() function we do not.

[alec]

So, PHP bug? What OS?

[casper]

It is a Debian 5 system. Could be a PHP bug. But sometimes this behavior is in the rand() and sometimes it is in the mt_rand(). Shifting year over year. Maybe it is better to combine rand() and mt_rand() with an additional timestamp? And than make an MD5 hash on that.

In that situation it doesn't matter if rand() or mt_rand() gives the same values over and over again on a particular system. The and result will be different each time.

[alec]

Yeah, I think we could concatenate $random with $this->ip and $this->start and create md5 from this.

[bepi]

1) Wait if you are behind a proxy the IP is all the time the same for all users behind it. Instead use the user name? uniqid(rand(), true) + $username + $some_other_random_junk_as_filler (the filler is if you want have all the id of same length)

2) the md5 is did to add entropy is possible use also an SHA?

example
$foo_random = md5(uniqid(rand(), true) . $username . $some_other_random_junk_as_filler . sha1(mt_rand());

3) why not use ​http://www.php.net/manual/en/function.session-regenerate-id.php ?

4) last point and use a table on DB (a tabe in memory). Where you store the user name and the actual ID with a unique attribute? Whit this you have the proof that no one use the same ID and the numbers of user of a roundcube installation is always small for the power of a DB. For my case the number of total user is 150 but connected is often less than 100. Also if one has 2000 of user the check of an id (unique) on DB is fast.

5) sorry for my ugly English!

thank you

[casper]

I think the example on point 2 is nice, because you use different functions. If one of them is failing, you still will get a real random string. The problem with the username, is that this ID is generated before a user logs in.

But I was also wondering why Roundcube does not use the default regenerate_id() function.

[till]

Replying to casper:

It is a Debian 5 system. Could be a PHP bug. But sometimes this behavior is in the rand() and sometimes it is in the mt_rand(). Shifting year over year. Maybe it is better to combine rand() and mt_rand() with an additional timestamp? And than make an MD5 hash on that.

In that situation it doesn't matter if rand() or mt_rand() gives the same values over and over again on a particular system. The and result will be different each time.

Can you share your exact PHP version and also a small script that demoes duplicate IDs?

[casper]

PHP Version => 5.2.17
System => Linux hostname 2.6.26-2-686 #1 SMP Mon Jun 21 05:58:44 UTC 2010 i686
Build Date => Feb 16 2011 17:05:39
Configure Command => './configure' '--with-apxs2' '--with-curl=/usr/local/lib' '--with-gd' '--enable-gd-native-ttf' '--with-ttf' '--enable-exif' '--with-gettext' '--with-jpeg-dir=/usr/local/lib' '--with-freetype-dir=/usr/local/lib' '--with-kerberos' '--with-openssl' '--with-mcrypt' '--with-mhash' '--with-mysql=/usr/local/mysql' '--with-mysqli=/usr/local/mysql/bin/mysql_config' '--with-pdo-mysql=/usr/local/mysql' '--with-pear' '--with-imap=/usr/local/imap-2007e' '--with-imap-ssl=/usr/local/imap-2007e' '--with-png-dir=/usr/local/lib' '--with-zlib' '--with-zlib-dir=/usr/local/lib' '--enable-zip' '--with-iconv=/usr/local' '--enable-bcmath' '--enable-calendar' '--enable-ftp' '--enable-magic-quotes' '--enable-sockets' '--enable-mbstring' '--enable-soap'

Mt_rand() does not give the same numbers in one single script, but it does when one script ran several times. So maybe a bug in the feeding of mt_rand()?

[bepi]

I have the bug on a debian lenny

php -v
PHP 5.2.6-1+lenny9 with Suhosin-Patch 0.9.6.2

[thomasb]

Replying to casper:

I think the example on point 2 is nice, because you use different functions. If one of them is failing, you still will get a real random string. The problem with the username, is that this ID is generated before a user logs in.

Actually the user name is available because regenerate_is() is called after the user successfully authenticated and the actual session begins.

But I was also wondering why Roundcube does not use the default regenerate_id() function.

session_regenerate_id() could be a good replacement. But we should carefully investigate if that function doesn't suffer of the non-unique random number as rand() and mt_rand(). If the underlying OS fails to create real random numbers, session_regenerate_id() could be affected as well.

[alec]

Scripts to check the bug existence. Save both files to some directory and run session.sh from there:

• session.php:

  <?php
  $randval = '0123456789abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ';
  for ($random = '', $i=1; $i <= 32; $i++) {
     $random .= substr($randval, mt_rand(0,(strlen($randval) - 1)), 1);
  }
  echo "$random\n";
  

• session.sh

  #!/bin/sh
  for i in {1..256}
  do
    php ./session.php >> ./session.out
  done
  
  LINES=`cat ./session.out | wc -l`
  cat ./session.out | sort | uniq > ./session.uniq
  UNIQ=`cat ./session.uniq | wc -l`
  
  if [ $LINES == $UNIQ ]
  then
    echo "OK (NO BUG)"
  else
    echo "BUG!"
  fi
  

No bug on PHP 5.3.5-pl0-gentoo.

[casper]

Replying to alec:

Scripts to check the bug existence.

When I run your script, it says 'no bug'. Also if I add a sleep of 2 seconds in the loop.

But when I run the session.php manually through Apache, these are the results. Multiple times I get the same values:

qqapHrEQi7r2gELtQyHsRtUV5DdKaapo
yZm2Pp39m1vkdjAQeF5BOcOjJu5snmPg
EmjmQV9aCJ75MobE9gxaKUewVKIfOmjN
cxsrvwMWuYgmF9hly5UhzIFD2JYNGYAB
PwxTDtplVNSg0gvzG6nriz1XdkxEw5el
oh6jzyg4oVTwX3e6A2bDf2eudWiJYMZF
VAtNgASebciGJmf7UR5GtFnnKMVxscWk
Bf7TzUJujaKG2Dpw2IXtBttdKPG2v16R
TQ9qWUiVvwsA5kLfEw6cNKXJyp7tfzSZ
E2UvrX0CpM3VuGqFnMcPhoNOLSPv48Fh
1FWMfv9b1p5DBhofS9Lt4QhpdEd7ReBg
dW4exQ2T9nEDwTXqWfiN3WxukcKzRFuW
UpebeE96CciYdXRNHAwqGn6tYsCYo568
fC0TmC2CfWwjmmqNGiCUA7pAYb37dGGs
QV12Z66WsWNfL7jIGYqLkjSDuIQpMoYy
ofnn0GD8CDw5flA9Li0P3gEsVeLxQMjh
nT4ZrWIsutdmwaNrynbONEYMP0IAR266
yZm2Pp39m1vkdjAQeF5BOcOjJu5snmPg
hTioh9xyrqgGk3rFJBNsbe90Fm5tSAdT
PTDCcQPIfJFZU9qiC4YD4Lb1F5U2l0kS
SjmHauqd4vmbxG32UFCMH3uOf4cgUStT
a3rbTxvAMOMSJvtGAm1xGG38AaHfVNja
xfvMx0RaZQk7Ux4SS86FLLqHFq43VMoO
I5zUTtelcWMujHzn4HcXhkO0C0wRiMZC
x5i1mqNvYiVJ2qrvUMTsKNcUvab9WrY2
5o5r0PXHC7xkzbtsabXIJ5bUd2ofwz8G
sI4olSx1nRnqGrPuEsBP2eHrn8AGzfxT
dW4exQ2T9nEDwTXqWfiN3WxukcKzRFuW
mmm7Wsb057gGi6cwvdvsAW7rjGjlJtFD
NL1LOTPFAlW2y2DLsvvj9kai9Ismi5Ig
81mRlZkhe2sbZ33rywCQu39vn7ioIDA4
EMWvpmQef1B4LKQch010n79sUaWaxYSO
bFHF9EkFvTo26eo1d59mSoNyx3yf9IPJ
qfTZ8h1BdVBituWG7Jm7XwcCReq4Y6EH
rgoAEtkswEJi1K4BONqgHEsPTVzaoDRc
brRFsCkRrM4WRDQ0SOZ7m4sItUhtOEdY
aKdgTD0uwL2fw049d99LWKRQQiS50nJi
yZm2Pp39m1vkdjAQeF5BOcOjJu5snmPg
RaKKWz2qQcOm099FphjLQlRMa6AVM7vE
2Sl2z4C8yPKJtCT61FsxTXPy0LXotjeS
fZ4cLGnAt1Z9P3kgdMck02tdvD2991th
dW4exQ2T9nEDwTXqWfiN3WxukcKzRFuW
38yu2XdafNefSIb5owLemFIiNkzXOZju
yZm2Pp39m1vkdjAQeF5BOcOjJu5snmPg
yZm2Pp39m1vkdjAQeF5BOcOjJu5snmPg
02xh2y7azodS0RUqeDwzHM2IOtRKUzhu
dW4exQ2T9nEDwTXqWfiN3WxukcKzRFuW
dW4exQ2T9nEDwTXqWfiN3WxukcKzRFuW
ExeT1suRmT5CEjPXfVq615vJDyV9kMVQ
ypUydGbl9QELk4mqohs9ekAx4kvAtdJB
SjmHauqd4vmbxG32UFCMH3uOf4cgUStT
BftgouIbToPRfu0MtnyuqjZj1rfSOxQR
HZs4AeMqaMljU5J0GPe0qfivJfS6DTUl
dz4JIRrSsjyqOK2LxELyJLvBvTdxmMr1
OZgA7V9GlBU5nLrxKjql6gJQ3Ky1GIN1
SjmHauqd4vmbxG32UFCMH3uOf4cgUStT
mUTBWXNxo0ZIioBwJgS7fBC2Qw7Y2opr
ZEM5hil0crHQXr69or7Ku8u1YSpIPniT
mUTBWXNxo0ZIioBwJgS7fBC2Qw7Y2opr
Z5ugB87uMrO8Pr9g3fqLl11DhgUKIs9d
SjmHauqd4vmbxG32UFCMH3uOf4cgUStT
9zhw1rAxYnZtCWSHQ57DC8U3bBOt8Xhj
0iI3gDKKzxh8WRwYleX1hZKyJPPYIXdc
rRO93DVJuLClGIiaYTjTaVF06gVm15r5
wOs2rnTSNYDUpgPsCuUYOmp8ZhWQE4Px
7lRpnkWLzmNXwA2PizXnkyWyOp217lwE
KGP1raFH5hUZlxYj4EKY5ICRq9WLIKZB

[casper]

When I change:

php ./session.php >> ./session.out

to

curl ​http://domain/session.php >> ./session.out

It says BUG!

[thomasb]

Please also test with the following script:

<?php

session_start();
echo session_id() . "\n";
session_regenerate_id(true);
echo session_id() . "\n";

?>

I just ran it 25600 times on Mac OS Y with Apache 2 and all generated session IDs were unique. This proves the reliability of the session_* functions (at least on Mac OS)

[casper]

I ran it 25000 times also and it says "OK (NO BUG)", on the same server.

I changed the script to prevent a "headers already sent" message:

session_start();
$session1 = session_id() . "\n";
session_regenerate_id(true);
echo $session1;
echo session_id() . "\n";

[thomasb]

OK, so I guess using session_regenerate_id() would fix this issue. Additional checks for existing records in sessions table after session_regenerate_id() could optionally be added.

[thomasb]

Changed to use session_regenerate_id() in [fb061aae]