January 2005 - dev - OTRS mailing lists

Re: [dev] Bug & Security Risk: escalation notification sent to wrong users
by Martin Edenhofer 08 Jan '05

08 Jan '05

Hi Robert, Martin Edenhofer schrieb: > thanks for your info. It's fixed now. > Please update for OTRS 1.3 > > o Kernel/Modules/AgentPreferences.pm 1.23.2.1 > > o Kernel/System/Ticket.pm 1.139.2.2 > > Thanks for feedback and testing! > Thank you, dear Martin, for your more than prompt reaction - perfect! That means it's working now? > With best regards, > > Robert Kehl -Martin -- Powered by OTRS-WebMail (http://otrs.org/)

2 1

Re: [dev] Bug & Security Risk: escalation notification sent to wrong users
by Martin Edenhofer 07 Jan '05

07 Jan '05

Hi Robert, thanks for your info. It's fixed now. Please update for OTRS 1.3 o Kernel/Modules/AgentPreferences.pm 1.23.2.1 o Kernel/System/Ticket.pm 1.139.2.2 Thanks for feedback and testing! -Martin -- ((otrs.de)) :: OTRS GmbH :: Norsk-Data-Str. 1 :: 61352 Bad Homburg http://www.otrs.de/ :: Manage your communication!

2 1

Bug & Security Risk: escalation notification sent to wrong users
by Robert Kehl 07 Jan '05

07 Jan '05

Hi all! I'm hereby reporting a bug within OTRS, discovered and reproduced on a mid-sized OTRS 1.3.2 installation, having some hundred agents and customers. It's a system being used internally only, with about one hundred queues and corresponding groups in a same amount. Imagine the following situation: Let Paul have the user_id 20 and be a member of the three groups A, B and C with 'rw' rights on each. There are three queues QA, QB and QC with each of the three groups being assigned to one of them. Let them have the IDs 10, 11 and 12. So, Paul has full rights on QA, QB and QC. He once assigned all of them (and eventually others, too, which doesn't matter here) to his personal queues ("My Queues"), resulting in at least these three entries in the table 'personal_queues' in the database. user_id queue_id -------- -------- 20 10 20 11 20 12 This way, Paul receives mails when tickets escalate in (at least one of) the queues QA, QB or QC - let the system be properly set up to perform that way via the GenericAgent. One day, Paul's admin decides Paul does not need 'rw' rights on QA and QB. He revokes the permissions, leaving perhaps some minor rights behind, such as 'move_into' or 'create'. It does not count which rights are left, as the 'rw' right is needed to actually work on a ticket. So far, so good. Now we come to the problem: Paul continues to receive the escalation notifications from QA and QB in his inbox, but lacking the 'rw' right he is not able to work on the tickets to de-escalate them. Depending on the permissions left behind, he might not even be able to actually view the tickets. He will for sure be greatly annoyed of all the useless escalation mails. Even worse, those escalation notifications might reveal information that Paul is not supposed to see at all - think of QA or QB containing confidential information. Depending on the contents of the escalation mail template, a lot might be revealed. Looking into the source code I found the responsible module Kernel::System::GenericAgent::NotifyAgentGroupOfCustomQueue building the group of users to be notified from the table 'personal_queues', thereby only checking for the validity of the agents in question, but not their permissions on the queue containing the escalated ticket. Additionally, no change is being made to the table 'personal_queues' at the time an agents' group permissions are changed (in fact meaning hereby it is being lowered) to prevent the above situation from occurring in the first place. I discovered a security risk involved in this issue, too: A malicious agent could potentially misuse the "My Queues" feature to gain more information than he/she is allowed to. All is needed is to construct a valid HTTP request (ie. a link), claiming queues by their ids for "My Queues" one would normally not be allowed to choose. See the following, clear and simple example. Try it out while being logged into OTRS using a test account by copying it as a whole into the address line of your browser: <http://localhost/otrs/index.pl ?Action=AgentPreferences &Subaction=UpdateCustomQueues &QueueID=1&QueueID=2&QueueID=3&QueueID=4&QueueID=5 &QueueID=6&QueueID=7&QueueID=8&QueueID=9&QueueID=10> You may continue the &QueueID=X entries as wanted and as depending on the installation to be attacked. In fact, OTRS does not check if the queue exists at all, so, a loop from 1 to a _very_ high number would most surely catch all queues. Leaving this as an ugly exercise to the reader. ;P Afterwards, the attacker will be informed about escalated tickets, which he/she were normally not allowed to. For sure a malicious user would never complain to the admins about getting escalation mails for those tickets, as this were the goal to achive at least. Despite the above described security risk, the situation can be worked around from the agents' side by simply saving their personal queues, ie. by once clicking the 'Update' button underneath the 'My Queues' box on the Preferences page. Thereby, every entry for that specific user is at first deleted from the personal_queues table and the correct ones (meaning the submitted ones, see above!) are re-added again. The agents get rid of unusable escalation mails. So, what's missing, at least in OTRS 1.x at the time of this writing, are checks, that... 1) ...determine the agents' actual permissions on the queues he/she is about to receive an escalation mail from (and probably other notifications, which I did not check) at the time of sending that mail. 2) ...prevent OTRS from leaving behind those unwanted zombie entries in the table 'personal_queues' when a group's 'rw' permission is revoked at least. 3) ...a check to not allow adding queues to "My Queues" one has no 'xyz' right on, at least for being 'xyz' = 'rw'. Hopefully this report helps developing OTRS furthermore. This report is filed as bug #659: http://bugs.otrs.org/show_bug.cgi?id=659 With kind regards, Robert Kehl

1 0