While it is still unclear whether or not there is a problem with bin/html2text.php (http://trac.roundcube.net/ticket/1485618), maybe it's worth considering adding session checking to all of the utilities in the bin directory. If a vulnerability exists in a utility, then having a session check will limit or complicate its exploitation.
The way quotaimg.php was doing session checking could be used in the other utilities. (quotaimg.php's session checking was removed in October: http://trac.roundcube.net/changeset/2012).
-kris
Kris Steinhoff wrote:
While it is still unclear whether or not there is a problem with bin/html2text.php (http://trac.roundcube.net/ticket/1485618), maybe it's worth considering adding session checking to all of the utilities in the bin directory. If a vulnerability exists in a utility, then having a session check will limit or complicate its exploitation.
The way quotaimg.php was doing session checking could be used in the other utilities. (quotaimg.php's session checking was removed in October: http://trac.roundcube.net/changeset/2012).
-kris
I have never seen the quota in the works as my environment does not yet require quotas for users. Is worth to have it as an image? A two-cell table styled to produce a "progress bar" may be a simpler and more efficient solution. -- Dennis _______________________________________________ List info: http://lists.roundcube.net/dev/
On Tue, Dec 9, 2008 at 8:40 PM, Kris Steinhoff steinhof@umich.edu wrote:
While it is still unclear whether or not there is a problem with bin/html2text.php (http://trac.roundcube.net/ticket/1485618), maybe it's worth considering adding session checking to all of the utilities in the bin directory. If a vulnerability exists in a utility, then having a session check will limit or complicate its exploitation.
The way quotaimg.php was doing session checking could be used in the other utilities. (quotaimg.php's session checking was removed in October: http://trac.roundcube.net/changeset/2012).
Wow, thanks for pointing that out.
@Thomas: Can we roll back in there? The reason the code is in there is that otherwise people can "execute" quotaimg.php without being logged in. I know that a log is not the ultimate security measure (malicious user logged in ;-), but it is worse without.
Reason why I include it is, there are scripts in the wild that run DoS attacks on servers by requesting the quota functions thus rending images (again, and again, and again) and in the end creating a lot of load on the server which can lead to a crash.
Till _______________________________________________ List info: http://lists.roundcube.net/dev/
On Wed, Dec 10, 2008 at 13:43, till till@php.net wrote:
On Tue, Dec 9, 2008 at 8:40 PM, Kris Steinhoff steinhof@umich.edu wrote:
While it is still unclear whether or not there is a problem with bin/html2text.php (http://trac.roundcube.net/ticket/1485618), maybe it's worth considering adding session checking to all of the utilities in the bin directory. If a vulnerability exists in a utility, then having a session check will limit or complicate its exploitation.
The way quotaimg.php was doing session checking could be used in the other utilities. (quotaimg.php's session checking was removed in October: http://trac.roundcube.net/changeset/2012).
Wow, thanks for pointing that out.
@Thomas: Can we roll back in there? The reason the code is in there is that otherwise people can "execute" quotaimg.php without being logged in. I know that a log is not the ultimate security measure (malicious user logged in ;-), but it is worse without.
Actually I don't see a real reason why a script that does not require a session state should have to check the session (and maybe even do an IMAP login?). Adding a session check will probably cause even more load because there are more classes to be included and instantiated and the database is queried since the session info is stored there.
Reason why I include it is, there are scripts in the wild that run DoS attacks on servers by requesting the quota functions thus rending images (again, and again, and again) and in the end creating a lot of load on the server which can lead to a crash.
In this particular case we need to investigate if the image rendering causes more load than the session checking (database!).
However, if one is looking to DoS your server there are other vulnerabilities than the quotaimg or the html2text script. What about the login page? This will not only put heavy load on the web server but also the IMAP server.
If you guys think we should add this, then I'll not revert it this time :-)
~Thomas _______________________________________________ List info: http://lists.roundcube.net/dev/
On Wed, Dec 10, 2008 at 6:00 PM, Thomas Bruederli roundcube@gmail.com wrote:
On Wed, Dec 10, 2008 at 13:43, till till@php.net wrote:
On Tue, Dec 9, 2008 at 8:40 PM, Kris Steinhoff steinhof@umich.edu wrote:
While it is still unclear whether or not there is a problem with bin/html2text.php (http://trac.roundcube.net/ticket/1485618), maybe it's worth considering adding session checking to all of the utilities in the bin directory. If a vulnerability exists in a utility, then having a session check will limit or complicate its exploitation.
The way quotaimg.php was doing session checking could be used in the other utilities. (quotaimg.php's session checking was removed in October: http://trac.roundcube.net/changeset/2012).
Wow, thanks for pointing that out.
@Thomas: Can we roll back in there? The reason the code is in there is that otherwise people can "execute" quotaimg.php without being logged in. I know that a log is not the ultimate security measure (malicious user logged in ;-), but it is worse without.
Actually I don't see a real reason why a script that does not require a session state should have to check the session (and maybe even do an IMAP login?). Adding a session check will probably cause even more load because there are more classes to be included and instantiated and the database is queried since the session info is stored there.
Reason why I include it is, there are scripts in the wild that run DoS attacks on servers by requesting the quota functions thus rending images (again, and again, and again) and in the end creating a lot of load on the server which can lead to a crash.
In this particular case we need to investigate if the image rendering causes more load than the session checking (database!).
It's a trade-off, imho. Speed vs. "security".
However, if one is looking to DoS your server there are other vulnerabilities than the quotaimg or the html2text script. What about the login page? This will not only put heavy load on the web server but also the IMAP server.
I guess we could implement a captcha there -- if we notice a lot of failed attempts. No idea how easy it is to implement it though. There's no ultimate security per se.
If you guys think we should add this, then I'll not revert it this time :-)
~Thomas
List info: http://lists.roundcube.net/dev/
On 12/10/08 2:50 PM, till wrote:
On Wed, Dec 10, 2008 at 6:00 PM, Thomas Bruederli roundcube@gmail.com wrote:
On Wed, Dec 10, 2008 at 13:43, till till@php.net wrote:
On Tue, Dec 9, 2008 at 8:40 PM, Kris Steinhoff steinhof@umich.edu wrote:
While it is still unclear whether or not there is a problem with bin/html2text.php (http://trac.roundcube.net/ticket/1485618), maybe it's worth considering adding session checking to all of the utilities in the bin directory. If a vulnerability exists in a utility, then having a session check will limit or complicate its exploitation.
The way quotaimg.php was doing session checking could be used in the other utilities. (quotaimg.php's session checking was removed in October: http://trac.roundcube.net/changeset/2012).
Wow, thanks for pointing that out.
@Thomas: Can we roll back in there? The reason the code is in there is that otherwise people can "execute" quotaimg.php without being logged in. I know that a log is not the ultimate security measure (malicious user logged in ;-), but it is worse without.
Actually I don't see a real reason why a script that does not require a session state should have to check the session (and maybe even do an IMAP login?). Adding a session check will probably cause even more load because there are more classes to be included and instantiated and the database is queried since the session info is stored there.
Reason why I include it is, there are scripts in the wild that run DoS attacks on servers by requesting the quota functions thus rending images (again, and again, and again) and in the end creating a lot of load on the server which can lead to a crash.
In this particular case we need to investigate if the image rendering causes more load than the session checking (database!).
It's a trade-off, imho. Speed vs. "security".
However, if one is looking to DoS your server there are other vulnerabilities than the quotaimg or the html2text script. What about the login page? This will not only put heavy load on the web server but also the IMAP server.
I guess we could implement a captcha there -- if we notice a lot of failed attempts. No idea how easy it is to implement it though. There's no ultimate security per se.
If you guys think we should add this, then I'll not revert it this time :-)
~Thomas
The scripts in the bin directory may be slightly more vulnerable to denial of service attacks. But I'm more worried about the potential for bugs in those scripts (or stuff they call) that could be a vector for more serious attacks.
Usage of those scripts should be limited to users know to RoundCube.
If the added weight of creating the $RCMAIL instance is a concern, then perhaps we could use a different (lighter) approach to verifying that the user running the script is a valid RoundCube user.
-kris
List info: http://lists.roundcube.net/dev/
Kris Steinhoff wrote:
The scripts in the bin directory may be slightly more vulnerable to denial of service attacks. But I'm more worried about the potential for bugs in those scripts (or stuff they call) that could be a vector for more serious attacks.
Usage of those scripts should be limited to users know to RoundCube.
If the added weight of creating the $RCMAIL instance is a concern, then perhaps we could use a different (lighter) approach to verifying that the user running the script is a valid RoundCube user.
-kris
I strongly agree with Kris that it is preferable to spend a few more CPU cycles if it reduces the exposure of our systems to attack. Since we've recently found two of the three web scripts in that directory to be vulnerable, I find the trade-off to be very compelling.
I've created a ticket with a patch for this.
http://trac.roundcube.net/ticket/1485645
-Jim
List info: http://lists.roundcube.net/dev/
James E. Blair wrote:
I strongly agree with Kris that it is preferable to spend a few more CPU cycles if it reduces the exposure of our systems to attack. Since we've recently found two of the three web scripts in that directory to be vulnerable, I find the trade-off to be very compelling.
I've created a ticket with a patch for this.
+1 from me.
A.L.E.C wrote:
+1 from me.
... but then maybe it would be better to create .inc files (let's say in program/steps/util) like to deny direct access to those scripts like to other actions.
On Wed, Dec 24, 2008 at 8:57 AM, A.L.E.C alec@alec.pl wrote:
A.L.E.C wrote:
+1 from me.
... but then maybe it would be better to create .inc files (let's say in program/steps/util) like to deny direct access to those scripts like to other actions.
Yeah, we could probably avoid the duplicate code this way. ;-)
I'm in favour of this patch as well since it is basically what I did that already, but Thomas removed this part of my patch -- so what's the final decision? I don't feel like going back and forth.
Till _______________________________________________ List info: http://lists.roundcube.net/dev/
till wrote:
On Wed, Dec 24, 2008 at 8:57 AM, A.L.E.C alec@alec.pl wrote:
A.L.E.C wrote:
+1 from me.
... but then maybe it would be better to create .inc files (let's say in program/steps/util) like to deny direct access to those scripts like to other actions.
Yeah, we could probably avoid the duplicate code this way. ;-)
I'm in favour of this patch as well since it is basically what I did that already, but Thomas removed this part of my patch -- so what's the final decision? I don't feel like going back and forth.
Just added a simple session check for now: http://trac.roundcube.net/changeset/2187
~Thomas _______________________________________________ List info: http://lists.roundcube.net/dev/
-
A.L.E.C -
Dennis P. Nikolaenko -
James E. Blair -
Kris Steinhoff -
Thomas Bruederli -
till -
till