There's a couple of different classes that have showed up so far:
XSS within the application itself which would require some to click a
link or visit a malicious page that could then redirect or otherwise
force the browser to visit the roumdcube interface and would be able
to then execute javascript within their browser's session and the
context of their users. This isn't quite as serious as it requires a
targeted attack where the bad guy knows the url of the roundcube
interface being used.
Some of the others are a little bit more serious in that they allow
javascript within a malicious email. This is more dangerous since
the attacker just has to be able to send an email to a user they know
is using roundcube (easy to find out from mail headers) and the email
can automatically do whatever it wants with their acount, including
injecting a copy of itself into the signature field which is the
third class of vulnerability -- a permanent XSS where the signature
can contain javascript so that any time someone composes a new
message, malicious javascript that's been planted in their signature
(see above two methods for how to do that) the javascript can again
run, maintaining a semi-permanent infection of their account.
Good news is nothing shows a way to directly compromise the
application itself, or the server, so far they're all just javascript
that could compromise individual email accounts.
No need to rely on the early version number, RC is a great package!
I'm testing the application scanners themselves, not the
applications. As I said before, whether you'd like me to publicly
list roundcube as the open source webmail package I did testing with
(or just generically describe it as "open source webmail package") i
totally up to you guys, I'm cool either way.
I'll start by emailing you and Thomas off-list with more details and
examples of what I've found so far and we can take it from there.
-- Jordan Wiens Contributing Technology Editor, Security Network Computing/InformationWeek 352.871.5109 (m) jordanwiens (im)
On Aug 23, 2007, at 7:02 PM, till wrote:
Hey Jordan,
really depends on the nature of the bug. If they are severe, maybe email them to me and Thomas off-list? Otherwise, I have no issues if you used the trac and maybe kept the list up to date as well.
In general I agree to wait with disclosure until they are fixed/straightend out so people have a chance to update. Just keep in mind that we are 0.1-rc1 and be gentle! ;))
Till
On 8/23/07, Jordan Wiens jwiens@psifertex.com wrote:
Trying to send again now that I'm actually subscribed. Hopefully it'll make it through this time! Sorry for all the forward headers.
-- Jordan Wiens Contributing Technology Editor, Security Network Computing/InformationWeek 352.871.5109 (m) jordanwiens (im)
Begin forwarded message:
From: Jordan Wiens jwiens@nwc.com Date: August 12, 2007 6:35:34 PM EDT To: dev@lists.roundcube.net Subject: Fwd: roundcube vulnerability scan
Sent this to roundcube@gmail.com, but never heard back. Since this is a public list, I've removed descriptions of the raw vulnerabilities. Would prefer to handle those privately unless explicitly told otherwise. Feel free to contact me via email or phone.
-- Jordan Wiens Contributing Technology Editor, Security Network Computing/InformationWeek 352.871.5109 (m) jordanwiens (im)
Begin forwarded message:
From: Jordan Wiens jwiens@nwc.com Date: July 20, 2007 6:59:50 PM EDT To: roundcube@gmail.com Subject: roundcube vulnerability scan
I'm using roundcube as a test application for a review on web application vulnerability scanners (http:// www.networkcomputing.com/rollingreviews/Web-Applications- Scanners/) and as a result, I expect to have a variety of vulnerabilities discovered over the course of the review.
I wanted to email you to ask a couple of questions.
First, how should I submit bugs discovered? Just use trac? Will that make them public? Private email? Let me know what you prefer, I'm happy to do either.
Secondly, would you like me to publicly mention which open source webmail project I used for my testing? Or stay anonymous? I'd prefer to not make it public at the very least until all the flaws discovered are fixed, though I doubt that will be a problem since writing the articles takes a while to go through the whole magazine process. Other than that, I'll leave the option up to you as to whether you prefer to be discussed. Note that I don't plan on discussion the exact details of particular vulnerabilities, just the general class and types.
Anyway, I've already stumbled across a few ways to evade the cross- site scripting blocking filters when manually looking through the code to see what the application scanners will be up against.
Here's samples of vulns I've found so far that will automatically execute javascript without user action besides just opening the email:
<DELETED>
-- Jordan Wiens Contributing Editor, Security Network Computing/InformationWeek 352.871.5109 (m) jordanwiens (im)
List info: http://lists.roundcube.net/dev/