Access issues within core update function

[glamrock]

When updating today, I realized that Piwik doesn't follow its own access rules when applying core updates. Anonymous internet users are able to begin the core update process once the initial step is triggered. Crucially, they are able to see not only the version in use but also the structure of the database and which SQL queries will be performed during the update.

For Piwik sites without a proxy server blocking off-site connections, this could be a critical vulnerability as it reveals a large amount of information about the database, extensions in use, and other software installed on the server. Through this, a malicious visitor would be much better prepared to attack the site.

OS: Ubuntu Trusty 14.04 x64 Version: upgraded from version 2.16.2 to the new version 3.0.4.

Bug posted here after conversation with security@ (enclosed as they provide a workaround):

That's true and this could be an issue. 1) Would you please create an issue in our tracker here: https://github.com/piwik/piwik/issues

2) As a workaround, we recommend to put Piwik into maintenance mode, and then run the upgrade via the console: https://piwik.org/docs/update/#database-upgrade-for-high-traffic-piwik-servers Thanks for your report,

Matthieu Piwik Security team

[utrautmann]

@mattab This ticket is very old, but just today I had a discussion with a very security-sensitive customer of mine about it. The update to Matomo 5 took more than 1 hour for this customer (because of a lot of SQL transactions). During the entire time, the following screen with security-sensitive information was visible and accessible without having to be logged in in any way. I think this should be improved for security reasons.

[sgiehl]

When performing the update on command line, I would recommend to set the maintenance_mode config option, to restrict UI access in the meantime. This could maybe be set automatically, while performing core:update.

[utrautmann]

@sgiehl : But nothing is tracked in maintenance mode or am I misunderstanding that? If an update on a large installation takes so long, that would be a tracking data loss, which is also undesirable.

[sgiehl]

See this FAQ on how to update a large instance without loosing tracking data: https://matomo.org/faq/how-to-update/faq_20844/

[utrautmann]

In the linked FAQ, option 1 via web server log files or option 2 via Redis and Queuing is mentioned. However, option 2 is not recommended for major upgrades, which today, for example, was my reason to ask again about the status of this ticket. @mattab also explicitly talks about workarounds at the top of this issue.

Option 1 with web server log files is a rudimentary approach that is not a solution for fully professional tracking of large websites with events, content tracking, etc.

I have to honestly say that both options are not a solution for customers who use Matomo tracking on websites that track an immediate monetary business.

And it is precisely such websites and customers who are very security-sensitive and want to update Matomo without losing data.

Could it be possible to show this page (see screenshots above) only to authenticated superusers?

Edit: Another problem is that you cannot know or estimate beforehand how long the database update will take. You don't know which way to go (update via browser or update on console). On large websites, the super users in Matomo are often not on the same team as the IT operations team, which has access to the server at PHP level.