SEC Consult Security Advisory < 20051211-0 > ========================================================================== title: < Several XSS issues in Horde Framework, Kronolith Calendar, Mnemo Notes, Nag Tasks and Turba Addressbook > program: < Horde Application Framework + Modules > vulnerable version: < Horde: <= 3.0.7 Kronolith: <= 2.0.5 Mnemo: <= 2.0.2 Nag: <= 2.0.3 Turba: <= 2.0.4 > homepage: < http://www.horde.org > found: < 2005-12-02 > by: < Johannes Greil > / SEC Consult / www.sec-consult.com ========================================================================== ------------------- vendor description: ------------------- The Horde Project is about creating high quality Open Source applications, based on PHP and the Horde Framework. The guiding principles of the Horde Project are to create solid standards-based applications using intelligent object oriented design that, wherever possible, are designed to run on a wide range of platforms and backends. There is great emphasis on making Horde as friendly to non-English speakers as possible. The Horde Framework currently supports many localization features such as unicode and right-to-left text and generous users have contributed many translations for the framework and applications. ---------------------- vulnerabilty overview: ---------------------- Kronolith - Calendar Application ================================ view calendars: --------------- 1) An (authenticated) attacker can create a calendar (under "My Calendars") with any Javascript code in the name field ("Calendar Name") and change the permissions to make it public to all users of the system. If the victim (user of the system) clicks on the menu "My Calendars" to only view his calendars, all the public calendars will also show up and the script code of the attacker will be executed. delete events: -------------- 2) The title field of a calendar event is not properly sanitized when deleting an event. Kronolith asks for "Delete $title" and renders $title without further validation on the confirmation page. It poses a threat when using shared/public calendars, where users of the system have read and especially delete access to other users' calendar events. search events: -------------- 3) The Basic and Advanced Search functionality render the category and location field without sanitation. An attacker can make an event public and insert common search words in the title or other fields in combination with malicious code. A victim searching for a common word will get the script code as a result, which is executed immediately. The scripting code, which has been added as a new category, will also be rendered in Horde Options under "Category and Labels", but categories cannot be shared to other users. edit attendees: --------------- 4) An attacker can add script code as an attendee email address in an event. Viewing the event is enough to execute the code because the email address isn't being filtered. edit permissions: ----------------- 5) The popup window for editing the permissions of a (your own) calendar doesn't filter the title of a calendar and views it unfiltered. This cannot be remotely exploited. The victim must be subscribed to the public calendar in bug 2), 3) and 4) to be affected, 1) does work in every case. An attacker can implement "relogin trojan scripting code" to trick the users to enter their login name + passwords and take over the accounts. This also bypasses the session management features of the Horde Framework (stores IP and browser string in sessions hence the cookie alone isn't that helpful). Horde Framework: ================ 6) The Horde Framework itself also suffers from XSS flaws (e.g. identity field, category/labels, mobile phone field, importing files) where at least one them is exploitable which affects other modules such as Turba Address Book. E.g. when showing an Address Book entry, the "Mobile Phone" field is not being sanitized and an attacker can create a malicious contact with Javascript code in that field. There are different attack vectors, such as importing a contact via CSV file or accessing some shared Address Book with a malicious contact. Directly adding malicious code into the Mobile Phone field doesn't work because of the input validation in place. importing CSV files: -------------------- 7) E.g. the Date and Time Fields are not properly sanitized on the import pages in Kronolith, Mnemo and Nag (a Horde Template is affected). A specially crafted CSV file can be used to execute arbitrary code on a victim. It shall be noted that the victim has to import this preparted file on his own so e.g. some social engineering email is needed. Mnemo Note Manager && Nag Task List Manager: ============================================ There are also some input validation flaws in Mnemo and Nag (and maybe other modules as well). Mnemo: When creating a new notepad, the notepad's name isn't being filtered. Hence it is possible to insert any javascript code. Furthermore one can insert Javascript code in a shared notepad's name which can be remotely exploited (as always only when already authenticated). Nag: This module suffers from a similar problem as Mnemo, here the "Task List's Name" and also the shared Tasklists are affected. Nag also suffers from the "importing CSV file" issue mentioned above. ----------------- proof of concept: ----------------- Kronolith: 1) E.g. add "<script>alert("calname")</script>" as the "Calendar Name", change permissions to public read access and login with another user. Just click on "My Calendars" menu - the code will be executed immediately in the "Select a calendar" section and in the "My Free/Busy URL" field. 2) Create a new event in a public calendar and e.g. use <script>alert("title")</script>" as the title. make this event readable and deletable for other users. If the victim clicks on "Delete event" the script code will be executed. 3) Create an event with "<script>alert("category")</script>" as a new category name, or some code in the location field, and make it public. If a user searches for the word "category", the event with the malicious code will be found and the code executed. 4) Use "<script>alert("attendee")</script>" as an email address and add the attendee to a public event. The code will be executed when viewing the public event. Horde: 6) E.g. add script code to the "Mobile Phone" field of a contact that is shared to other people. You have to bypass Horde's input validation for that field, e.g. by importing a preparated contact via CSV file. After that the script code will be executed upon clicking on the contact. -------------------- vulnerable versions: -------------------- 'HORDE_VERSION', '3.0.7' and lower 'KRONOLITH_VERSION', 'H3 (2.0.5)' and lower 'MNEMO_VERSION', 'H3 (2.0.2)' and lower 'NAG_VERSION', 'H3 (2.0.3)' and lower 'TURBA_VERSION', 'H3 (2.0.4)' and lower -------------- vendor status: -------------- vendor notified: 2005-12-02 vendor response: 2005-12-02 first patches available in CVS: 2005-12-02 coordinated release date: 2005-12-11 The Horde developer team has been very responsive and working with them was exemplary. There were several other possible XSS problems in Horde's, Kronolith's and other modules' source which have been addressed by the developers after further digging through the code and fixing the reported problems, CVS archive: http://lists.horde.org/archives/cvs/Week-of-Mon-20051128/thread.html http://lists.horde.org/archives/cvs/Week-of-Mon-20051205/thread.html Greetings and special thanks to Chuck! --------- solution: --------- The versions of Horde, Kronolith, Mnemo, Nag and other modules have been bumped, their new releases can be obtained from http://www.horde.org Users are strongly urged to upgrade to the latest release of Horde and each application. The new Horde release fixes the cellphone field vulnerability for Turba (and any other applications displaying forms using Horde_Form_Type_cellphone); all of the other fixes are contained in the application that they affect. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ < Johannes Greil > / www.sec-consult.com / SGT ::: < tke, mei, bmu, dfa > ::: Reproducible: Always Steps to Reproduce:
Vapier please provide updated ebuilds.
done
vapier: Any idea if this also affects the 2.x series ? If it does, should we call for stable on the 3.x series ?
when i was coordinating the stuff with the horde devs, i also asked (the question was about kronolith, rest will be the same i guess): [22:00:20] <JG^> if 2.0.5 is affected by this, all of 2.0.x is, isn't it? what about 1.x? [22:01:23] <@chagenbu> so, i've got some more work to do, I'll look through nag and mnemo again as well, me or someone will roll the 2.0.x releases for nag, kronolith, mnemo [22:01:32] <@chagenbu> yeah, anything before the 2.0.x new releases. i only tested 2.0.x and horde 3, because i have no other installations. JG
there'll be a 3.0.9 horde rls shortly i guess because of this (not security related): http://bugs.horde.org/ticket/?id=3123
Back to ebuild. vapier please provide an updated ebuild.
ebuild for what ? they havent made a release so i cant do anything
easy, thought it was just about to happen and I didn't set it to upstream (before now).
sorry for the confusion ^^ 3.0.9 is available now. JG
3.0.9 in portage
The question still holds. The current stable series is horde-2.x, horde-3.x being in ~. If this affects both series, two solutions: - find a horde-2.x fix - mark horde-3.x as stable If this affects only horde-3.x this should be closed as noglsa.
Looks like it affects specific Horde3 files. If there is a similar vulnerability in Horde2 it won't be the same one anyway, so closing. Feel free to reopen if you disagree. The comment on the opportunity to test and mark stable Horde3 now that the 2.x series is deprecated still stands.
