[RCD] /bin utilities
steinhof at umich.edu
Wed Dec 10 22:23:43 CET 2008
On 12/10/08 2:50 PM, till wrote:
> On Wed, Dec 10, 2008 at 6:00 PM, Thomas Bruederli <roundcube at gmail.com> wrote:
>> On Wed, Dec 10, 2008 at 13:43, till <till at php.net> wrote:
>>> On Tue, Dec 9, 2008 at 8:40 PM, Kris Steinhoff <steinhof at 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:
>>> 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 :-)
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.
List info: http://lists.roundcube.net/dev/
More information about the Dev