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/