We're currently sitting at version 3.2.9. Version 3.3.3 is the latest available and there have been *several security releases* since we last upgraded.
I'm told that RT #6674 (https://rt.wikimedia.org/Ticket/Display.html?id=6674) is related to this as well.
Version: wmf-deployment
Severity: enhancement
URL: https://www.otrs.com/try/
| Status | Subtype | Assigned | Task | ||
|---|---|---|---|---|---|
| Invalid | None | T37717 Have one click spam button in all message views (like "zoom"/full message), not only in overview | |||
| Resolved | Matthewrbowker | T56755 Create OTRS patch for "1-click spam" disposal | |||
| Invalid | None | T63101 Install "Password Policy" add-on to OTRS for improved security | |||
| Resolved | Jgreen | T62271 Upgrade OTRS to 3.2.14 version |
For reference, the security releases are:
https://www.otrs.com/release-notes-otrs-help-desk-3-2-10/
https://www.otrs.com/release-notes-otrs-help-desk-3-2-10-2/
https://www.otrs.com/release-notes-otrs-help-desk-3-2-12/ (which currently doesn't work).
(In reply to comment #2)
How are the links you provided related to security? Why did you include a broken link?
(In reply to comment #3)
(In reply to comment #2)
How are the links you provided related to security? Why did you include a
broken link?
Ask OTRS? The message we all see when we log in is the following:
Product News
OTRS 3.3.3 is available! Please update now. (Release Note - Level: Minor)
OTRS 3.3.2 is available! Please update now. (Release Note - Level: Minor)
OTRS 3.3.1 is available! Please update now. (Release Note - Level: Minor)
OTRS 3.2.12 is available! Please update now. (Release Note - Level: Security)
OTRS 3.2.11 is available! Please update now. (Release Note - Level: Security)
OTRS 3.2.10 is available! Please update now. (Release Note - Level: Security)
The links I provided are the links they provided within those above words.
I should note, that this is probably a 2 part bug
The 3.2.X patches should ideally be applied sooner, and hopefully should be trivial to do.
Upgrade to 3.3 is likely to be quite a bit more involved work to do so
I see that otrs is calling 3.2.8-13 "security" releases (http://otrs.org/product.xml?Product=OTRS-3.2.9), but nothing in the release notes looks like a serious security issue. It doesn't look like any cve's have been issued since 3.2.9.
If anyone can find the details, I'm happy to add an opinion.
I'm changing the bug topic to 3.2.x--IMO we should keep the minor/security releases separate from the major version upgrade. The upgrade and tracking of latest 3.2.x is a no-brainer, somthing I've been intending to do but haven't had time due to fundraising obligations. The main hitch at this point is making sure that the version patches don't conflict with our own patches.
And this was released yesterday,
https://www.otrs.com/security-advisory-2014-01-csrf-issue-customer-web-interface/
So we need to update to 3.2.14. I can't tell how critical the vulnerable features are, so I'm not sure how urgent the upgrade is. But seems like something we should try to do soon.
me wrote:
Znuny (znuny.com) can assist. We have two options.
Who is the technical contact?
-Martin
me wrote:
Sorry, this are the correct urls (in english):
http://znuny.com/en/#!/advisory/ZSA-2014-01 http://znuny.com/en/#!/advisory/ZSA-2014-02
I can work on this. Let's go for the latest 3.2 release. I will review the release/upgrade information today.
I applied the fixed files per Martin's suggested workaround, so we should be in reasonably good shape security wise.
I still intend to upgrade us to 3.2.14 which is the latest 3.2.x release once I'm more confident on the order of operations for the upgrade.
I set up a test db+webserver instance on db78 and went through the reinstall process with 3.2.14. The OTRS packages needed reinstall as expected, and everything appeared to go smoothly.
When we do the upgrade on the live system we should run a database dump and web tree backup before making changes. I think we can use one of the slave db's to do this in parallel--so we shouldn't need a very long outage, under an hour.
So as far as I'm concerned we can schedule a maintenance window and go ahead with the upgrade.
Just let us know so we can notify our users ASAP when this outage will occur.
Thanks, Jeff.
The upgrade to 3.2.14 is scheduled for Wednesday Feb 12th, at 5AM UTC according to the deployment schedule.
Upgrade process notes:
disable iodine https/smtpd monitoring
disable db48 mysql monitoring
root@iodine:/usr/local/src# wget http://ftp.gwdg.de/pub/misc/otrs/otrs-3.2.14.tar.bz2
root@iodine:/opt# tar xjf /usr/local/src/otrs-3.2.14.tar.bz2
study otrs-3.2.14/UPGRADING.md and sanity check these upgrade instructions
root@iodine:~# /etc/init.d/puppet stop
root@iodine:~# /etc/init.d/apache2 stop
root@iodine:~# /etc/init.d/exim4 stop
root@iodine:~# rm /etc/cron.d/puppet /etc/cron.d/otrs
root@iodine:/opt# tar czf backup/otrs-3.2.9-20140206.tgz otrs-3.2.9
stop slave on db48, start dumping the otrs db there
root@iodine:/opt# rm otrs && ln -s otrs-3.2.14 otrs
root@iodine:/opt# cp otrs-3.2.9/Kernel/Config.pm otrs/Kernel/
root@iodine:/opt# ./otrs/bin/otrs.SetPermissions.pl --otrs-user=otrs --otrs-group=otrs --web-user=www-data --web-group=www-data /opt/otrs
root@iodine:/opt# ./otrs/bin/otrs.CheckDB.pl
follow database upgrade instructions in UPGRADING.md
on db1048.eqiad.wmnet, otrs database
ALTER TABLE dynamic_field ENGINE=InnoDB;
ALTER TABLE dynamic_field_value ENGINE=InnoDB;
ALTER TABLE gi_debugger_entry ENGINE=InnoDB;
ALTER TABLE gi_debugger_entry_content ENGINE=InnoDB;
ALTER TABLE gi_object_lock_state ENGINE=InnoDB;
ALTER TABLE gi_webservice_config ENGINE=InnoDB;
ALTER TABLE gi_webservice_config_history ENGINE=InnoDB;
ALTER TABLE notification_event ENGINE=InnoDB;
ALTER TABLE notification_event_item ENGINE=InnoDB;
ALTER TABLE pm_activity ENGINE=InnoDB;
ALTER TABLE pm_activity_dialog ENGINE=InnoDB;
ALTER TABLE pm_entity ENGINE=InnoDB;
ALTER TABLE pm_entity_sync ENGINE=InnoDB;
ALTER TABLE pm_process ENGINE=InnoDB;
ALTER TABLE pm_transition ENGINE=InnoDB;
ALTER TABLE pm_transition_action ENGINE=InnoDB;
ALTER TABLE scheduler_task_list ENGINE=InnoDB;
ALTER TABLE sessions ENGINE=InnoDB;
ALTER TABLE smime_signer_cert_relations ENGINE=InnoDB;
ALTER TABLE ticket_flag ENGINE=InnoDB;
ALTER TABLE virtual_fs ENGINE=InnoDB;
ALTER TABLE virtual_fs_db ENGINE=InnoDB;
ALTER TABLE virtual_fs_preferences ENGINE=InnoDB;
*NOTE* otrs.CheckDB.pl complains because the default storage engine for db1048 is myisam
jgreen declares this acceptable and moves on
root@iodine:/opt# /etc/init.d/apache2 start
ADMIN -> System Administration -> Package Manager
Reinstall will be under the ACTION column for each package
root@iodine:/opt# cp otrs-3.2.9/Kernel/Config/Files/ZZZA* otrs/Kernel/Config/Files/
root@iodine:/opt# ./otrs/bin/otrs.SetPermissions.pl --otrs-user=otrs --otrs-group=otrs --web-user=www-data --web-group=www-data /opt/otrs
root@iodine:/opt# /etc/init.d/apache2 restart
test functionality
root@iodine:~# /etc/init.d/exim4 start
root@iodine:~# puppetd -tv
send a mail to e.g. info-en and check that it shows up in OTRS
PROBLEMS
reenable iodine https/smtpd monitoring
restart slave on db48
reenable db48 mysql monitoring