Upstream has announced that versions 5.0.16 and 6.0.3 will be available soon (RCs are available now) and fix several security issues: http://owncloud.org/releases/Changelog http://mailman.owncloud.org/pipermail/testpilots/2014-April/000132.html http://mailman.owncloud.org/pipermail/devel/2014-April/000130.html The changelog will be posted here once it's released: http://owncloud.org/changelog/ But as you can see from the temporary changelog, they're going to be very unhelpful and not announce the security issues fixed until *two weeks* after the release, so we'll have to either release it with a generic advisory, hold the update until the details are available, or hold the advisory until later. Reproducible: Steps to Reproduce:
Whiteboard: (none) => MGA4TOO, MGA3TOO
The updated versions are available as of yesterday (April 29): http://mailman.owncloud.org/pipermail/devel/2014-April/000173.html
Updated packages uploaded for Mageia 3, Mageia 4, and Cauldron. As I mentioned in Comment 0, details on the security issues fixed won't be available for two weeks, so I'll just post a generic advisory for now, and we'll have to decide what we want to do about this. For now, it can at least be tested. Advisory: ======================== Updated owncloud packages fix security vulnerabilities: Owncloud versions 5.0.16 and 6.0.3 fix several unspecified security vulnerabilities, as well as many other bugs. See the upstream Changelog for more information. References: http://owncloud.org/changelog/ ======================== Updated packages in core/updates_testing: ======================== owncloud-5.0.16-1.mga3 owncloud-6.0.3-1.mga4 from SRPMS: owncloud-5.0.16-1.mga3.src.rpm owncloud-6.0.3-1.mga4.src.rpm
CC: (none) => mageiaVersion: Cauldron => 4Assignee: mageia => qa-bugsWhiteboard: MGA4TOO, MGA3TOO => MGA3TOO
Testing mga4 64 After updating, owncloud is not available. Had to restart httpd manually and then it completes the upgrade when next visited. It's fine when it has done that. Just missing the service restart/reload.
Whiteboard: MGA3TOO => MGA3TOO feedback
Are you sure you didn't have some PHP cache module enabled? ownCloud shouldn't need restart of web server.
CC: (none) => mageia
Owncloud includes a .conf file in %{webappconfdir} which will automatically trigger an httpd reload due to the filetriggers in the apache package.
Whiteboard: MGA3TOO feedback => MGA3TOO
It's actually showing segfaults in /var/log/httpd/error_log. Journalctl shows httpd being reloaded when the update is installed. # urpme owncloud # urpme php-suhosin # service httpd restart # rm -rf /usr/share/owncloud Trying again without suhosin, everything works as it should. Must be some suhosin setting to tight for it.
Ahh great, you found yet *another* httpd segfaulter in Mageia 4, most likely caused yet again by PHP (See Bug 13112 libzip/php-zip and Bug 12995 php-opcache for others). This is the first one where suhosin is implicated, but if it were as simple as a suhosin setting, suhosin would just be spitting out error messages, not causing segfaults. Although, given my experience in Bug 12995, please make sure that the crashes really don't happen with php-suhosin uninstalled when you have the current owncloud installed and then install the update. I just want to make sure this isn't another httpd reload crashes but httpd restart works fine deal. Anyway, I sincerely doubt there's anything that can be done about this on the owncloud side or that this is an owncloud problem. It is quite likely another PHP problem. As if this isn't all fun enough, even if you follow all of the instructions out there for debugging PHP/Apache segfaults, it just doesn't work in Mageia 4. Apache httpd just will not dump core or give a stack trace for some reason, making these things very hard to debug. The best I've been able to do is "strace httpd -X" to at least get a strace log to try to get some hint of where things go wrong. So I'll remove the feedback tag again (sorry!) as I don't believe this is an owncloud issue, but hopefully we can pin down the real source of it. Obviously if you do have php-opcache installed, you should remove it as this could just be Bug 12995. Otherwise, we'll probably end up needing to file another bug for this.
Debugging on IRC points to an issue with suhosin causing the segfaults when the page is refreshed. Ruled out apc being a problem. The update causes an httpd reload rather than restart but the segfaults clear when httpd is manually restarted, so causing a restart rather than reload would work around the problem.
In VirtualBox, M3, KDE, 32-bit Package(s) under test: owncloud default install of owncloud [root@localhost wilcal]# urpmi owncloud Package owncloud-5.0.15-1.mga3.noarch is already installed http://localhost/owncloud gets me the initialization page. I can create a user, log in then create a contact. I can create an event in the calendar and a text.txt file. In Files that is continiously displaying "Upgrading filesystem cache..." install owncloud from updates_testing [root@localhost wilcal]# urpmi owncloud Package owncloud-5.0.16-1.mga3.noarch is already installed http://localhost/owncloud opens, reinitializes and all the previous entered is there and I can create more. In Files "Upgrading filesystem cache..." is no longer being displayed Test platform: Intel Core i7-2600K Sandy Bridge 3.4GHz GIGABYTE GA-Z68X-UD3-B3 LGA 1155 MoBo GIGABYTE GV-N440D3-1GI Nvidia GeForce GT 440 (Fermi) 1GB RTL8111/8168B PCI Express 1Gbit Ethernet DRAM 16GB (4 x 4GB) Mageia 4 64-bit, Nvidia driver VirtualBox 4.3.6-1.mga4.x86_64.rpm
CC: (none) => wilcal.int
In VirtualBox, M3, KDE, 64-bit Package(s) under test: owncloud default install of owncloud [root@localhost wilcal]# urpmi owncloud Package owncloud-5.0.15-1.mga3.noarch is already installed http://localhost/owncloud gets me the initialization page. I can create a user, log in then create a contact. I can create an event in the calendar and a text.txt file. Did not see the "Upgrading filesystem cache..." thingy Can get to, and use, owncloud from another M4 on the LAN. install owncloud from updates_testing [root@localhost wilcal]# urpmi owncloud Package owncloud-5.0.16-1.mga3.noarch is already installed http://localhost/owncloud opens, reinitializes and all the previous entered is there and I can create more. From another M4 on the LAN it's now barking at me because I am an "untrusted domain" but it is responding. Test platform: Intel Core i7-2600K Sandy Bridge 3.4GHz GIGABYTE GA-Z68X-UD3-B3 LGA 1155 MoBo GIGABYTE GV-N440D3-1GI Nvidia GeForce GT 440 (Fermi) 1GB RTL8111/8168B PCI Express 1Gbit Ethernet DRAM 16GB (4 x 4GB) Mageia 4 64-bit, Nvidia driver VirtualBox 4.3.6-1.mga4.x86_64.rpm
In VirtualBox, M3, KDE, 32-bit Package(s) under test: owncloud default install of owncloud [root@localhost wilcal]# urpmi owncloud Package owncloud-6.0.2-1.mga4.noarch is already installed http://localhost/owncloud gets me the initialization page. I can create a user, log in then create a contact. I can create an event in the calendar and a text.txt file. Can get to, and use, owncloud from another M4 on the LAN. This all seems to work much better then the version on M3. The new, or open, document function does not seem to be functioning. install owncloud from updates_testing [root@localhost wilcal]# urpmi owncloud Package owncloud-6.0.3-1.mga4.noarch is already installed http://localhost/owncloud gets me the initialization page. I can create a user, log in then create a contact. I can create an event in the calendar and a text.txt file. The new, or open, document function does not seem to be functioning. Another M4 on the LAN is considered an "untrusted domain" Test platform: Intel Core i7-2600K Sandy Bridge 3.4GHz GIGABYTE GA-Z68X-UD3-B3 LGA 1155 MoBo GIGABYTE GV-N440D3-1GI Nvidia GeForce GT 440 (Fermi) 1GB RTL8111/8168B PCI Express 1Gbit Ethernet DRAM 16GB (4 x 4GB) Mageia 4 64-bit, Nvidia driver VirtualBox 4.3.6-1.mga4.x86_64.rpm
(In reply to William Kenney from comment #11) > In VirtualBox, M3, KDE, 32-bit Correct to > In VirtualBox, M4, KDE, 32-bit
Do you have php-suhosin installed Bill? it is by default with task-lamp IINM.
php-suhosin is installed as a Suggests of apache-mod_php, so yes, it would be installed by default. It would be interesting to know if Bill has removed it.
can't reproduce the issue with php-suhosin on my local server: php-suhosin is installed and the update of owncloud runs without any issues. HTTPD service reloaded automatically: [root@MediaCenter media]# systemctl status -l httpd.service httpd.service - The Apache HTTP Server Loaded: loaded (/usr/lib/systemd/system/httpd.service; enabled) Active: active (running) since Fr 2014-05-02 09:43:10 CEST; 10h ago Mai 02 19:56:24 MediaCenter systemd[1]: Reloading The Apache HTTP Server. Mai 02 19:56:24 MediaCenter httpd[8292]: AH00558: httpd: Could not reliably determine the server's qualified domain name, using 127.0.0.1. Set the 'ServerName' directive globally to suppress this me Mai 02 19:56:24 MediaCenter systemd[1]: Reloaded The Apache HTTP Server. visiting owncloud from remote computer, owncloud runs update-scripts automatically. system: mga4 64bit
CC: (none) => marc.lattemann
(In reply to David Walser from comment #14) > php-suhosin is installed as a Suggests of apache-mod_php, so yes, it would > be installed by default. It would be interesting to know if Bill has > removed it. Thanks all. This was my first round with owncloud. Now that I've gone through it once I'll go back through again looking at what's been mentioned here. And being a little smarter with it. I do have httpd ( Apache ) installed on all the test platforms and no I don't believe I removed apache-mod_php. Note, there appears to be a very big difference between owncloud 5 & 6.
In VirtualBox, M3, KDE, 32-bit Package(s) under test: owncloud apache-mod_php php-suhosin Installing apache-mod_php also installs php-suhosin Installing php-suhosin does not install apache-mod_php Installing owncloud installs apache-mod_php and php-suhosin default install of owncloud [root@localhost wilcal]# urpmi owncloud Package owncloud-5.0.15-1.mga3.noarch is already installed [root@localhost wilcal]# urpmi apache-mod_php Package apache-mod_php-5.4.27-1.mga3.i586 is already installed [root@localhost wilcal]# urpmi php-suhosin Package php-suhosin-0.9.34-0.0.git1fba865.4.mga3.i586 is already installed http://localhost/owncloud gets me the initialization page. I can create a user, log in then create a contact. I can create an event in the calendar. In Files that is continiously displaying "Upgrading filesystem cache..." and there does not seem to be any functionality to it. I can get to it from another M4 system on the LAN and I see the same thing with the files function. install owncloud from updates_testing [root@localhost wilcal]# urpmi owncloud Package owncloud-5.0.16-1.mga3.noarch is already installed [root@localhost wilcal]# urpmi apache-mod_php Package apache-mod_php-5.4.27-1.mga3.i586 is already installed [root@localhost wilcal]# urpmi php-suhosin Package php-suhosin-0.9.34-0.0.git1fba865.4.mga3.i586 is already installed http://localhost/owncloud opens, reinitializes and all the previous entered stuff is there and I can create more stuff. In Files now is "Nothing in here. Upload something!" I don't know how to upload something but it looks like this works now. If I attempt to access owncloud from another M4 system on the LAN I get the following message: "You are accessing the server from an untrusted domain." So clearly part of the security update was to turn this feature off. I tinkered with the conf file but it's over my head. Maybe this is working as well as can be expected? Test platform: Intel Core i7-2600K Sandy Bridge 3.4GHz GIGABYTE GA-Z68X-UD3-B3 LGA 1155 MoBo GIGABYTE GV-N440D3-1GI Nvidia GeForce GT 440 (Fermi) 1GB RTL8111/8168B PCI Express 1Gbit Ethernet DRAM 16GB (4 x 4GB) Mageia 4 64-bit, Nvidia driver VirtualBox 4.3.6-1.mga4.x86_64.rpm
In VirtualBox, M4, KDE, 32-bit Package(s) under test: owncloud apache-mod_php php-suhosin Installing owncloud installs apache-mod_php and php-suhosin default install of owncloud [root@localhost wilcal]# urpmi owncloud Package owncloud-6.0.2-1.mga4.noarch is already installed [root@localhost wilcal]# urpmi apache-mod_php Package apache-mod_php-5.5.11-1.mga4.i586 is already installed [root@localhost wilcal]# urpmi php-suhosin Package php-suhosin-0.9.33-5.mga4.i586 is already installed http://localhost/owncloud gets me the initialization page. I can create a user, log in then create a contact. I can create an event in the calendar. In Files I can easily create and save a text file. I can get to it from another M4 system on the LAN and everything appers to be fully functional. install owncloud from updates_testing [root@localhost wilcal]# urpmi owncloud Package owncloud-6.0.3-1.mga4.noarch is already installed [root@localhost wilcal]# urpmi apache-mod_php Package apache-mod_php-5.5.11-1.mga4.i586 is already installed [root@localhost wilcal]# urpmi php-suhosin Package php-suhosin-0.9.33-5.mga4.i586 is already installed http://localhost/owncloud opens, reinitializes and all the previous entered stuff is there and I can create more stuff. If I attempt to access owncloud from another M4 system on the LAN I get the following message: "You are accessing the server from an untrusted domain." So clearly part of the security update was to turn this feature off. Ver 6 of this thing is clearly way better then Ver 5 and is actually quite useful. I ain't gonna figure out how to use the config file. Test platform: Intel Core i7-2600K Sandy Bridge 3.4GHz GIGABYTE GA-Z68X-UD3-B3 LGA 1155 MoBo GIGABYTE GV-N440D3-1GI Nvidia GeForce GT 440 (Fermi) 1GB RTL8111/8168B PCI Express 1Gbit Ethernet DRAM 16GB (4 x 4GB) Mageia 4 64-bit, Nvidia driver VirtualBox 4.3.6-1.mga4.x86_64.rpm
Can anyone else think of other ways to test this thing?
I've tested on two separate mga4 systems (32 & 64) and found the same segfault directly after the package is installed. On both it is fixed by restarting httpd. Install from updates, create the admin account and login, upload a random file, logout, install the update, refresh the page - each refresh causes a segfault, which firefox shows as 'The connection was reset'. I have a quite complete php installation on both machines from testing php updates, which may be the difference from others. It would be good if this could restart httpd as a workaround rather than reload it.
Whiteboard: MGA3TOO => MGA3TOO mga3-32-ok mga3-64-ok
Whiteboard: MGA3TOO mga3-32-ok mga3-64-ok => MGA3TOO feedback mga3-32-ok mga3-64-ok
Owncloud will not be hardcoding a call to restart httpd. It doesn't even do the reload itself currently, technically. It's handled by a filetrigger from the Apache package itself. Also, William wasn't able to reproduce the issue from what I understand, so it doesn't affect everyone. It'd be nice to fix the actual issue instead of trying to workaround it, but we'd have to know what's actually causing it first. Anyway, it'll have to be dealt with later. As far as I can see, this package is ready to ship. Vulnerability details haven't been released yet, so we'll just have to decide what to do about that. I guess they'll be coming in about another week.
Whiteboard: MGA3TOO feedback mga3-32-ok mga3-64-ok => MGA3TOO mga3-32-ok mga3-64-ok
I'm comfortable with pushing this one along. The M4 version seems to me to be much more friendly and I suspect that will be the bulk of the installs.
Advisory uploaded. In good conscience, I'll have to let you validate it William.
Whiteboard: MGA3TOO mga3-32-ok mga3-64-ok => MGA3TOO advisory mga3-32-ok mga3-64-ok
I'm sorry we couldn't quickly determine the source of the issue that you saw. Please do file a bug about it, so hopefully some more knowledgeable people will have a chance to investigate it.
With pleasure claire For me this update works fine. Testing complete for mga3 32-bit & 64-bit Testing complete for mga4 32-bit & 64-bit Validating the update. Could someone from the sysadmin team push this to updates. Thanks
Keywords: (none) => validated_updateWhiteboard: MGA3TOO advisory mga3-32-ok mga3-64-ok => MGA3TOO advisory mga3-32-ok mga3-64-ok mga4-32-ok mga4-64-okCC: (none) => sysadmin-bugs
Update pushed: http://advisories.mageia.org/MGASA-2014-0209.html
Status: NEW => RESOLVEDCC: (none) => tmbResolution: (none) => FIXED
URL: (none) => http://lwn.net/Vulnerabilities/599084/
Here's full advisories now that the details are available. Advisory (Mageia 4): ======================== Updated owncloud packages fix security vulnerabilities: In ownCloud before 6.0.3, due to not sanitising all user provided input the below mentioned ownCloud versions are vulnerable against several XSS attack vectors in the Documents, Gallery, and ownCloud Core components (CVE-2014-3832, CVE-2014-3833). In ownCloud before 6.0.3, due to not verifying whether an user has permission to rename files of other users an authenticated user could rename files of other users without permission Also, due to not verifying whether an user has been granted access to an address book, authenticated users are able to access arbitrary contacts of other users (CVE-2014-3834). In ownCloud before 6.0.3, due to not verifying whether an user has been granted access to add external storages an authenticated user could even mount external storage (e.g. SMB/FTP/etc.) without permission (CVE-2014-3835). In ownCloud before 6.0.3, due to not verifying whether a request was intentionally provided by the user who submitted an request the documents application is vulnerable against several CSRF attacks. An attacker could use this to arbitrarily modify existing files or rename them (CVE-2014-3836). In ownCloud before 6.0.3, due to using the auto-incrementing file_id instead of the random generated token to access files in the documents app an authenticated users could enumerate shared files of other users (CVE-2014-3837). In ownCloud before 6.0.3, due to an improper authorization check in core an attacker with access to at least two user account is able to access the file names of other users (CVE-2014-3838). In ownCloud before 6.0.3, due to the deserialization of unstrusted data in core an attacker might be able to delete arbitrary files from the filesystem or executing arbitrary SQL queries (CVE-2014-3839). References: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2014-3832 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2014-3833 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2014-3834 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2014-3835 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2014-3836 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2014-3837 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2014-3838 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2014-3839 http://owncloud.org/security/advisory/?id=oC-SA-2014-010 http://owncloud.org/security/advisory/?id=oC-SA-2014-011 http://owncloud.org/security/advisory/?id=oC-SA-2014-012 http://owncloud.org/security/advisory/?id=oC-SA-2014-013 http://owncloud.org/security/advisory/?id=oC-SA-2014-014 http://owncloud.org/security/advisory/?id=oC-SA-2014-015 http://owncloud.org/security/advisory/?id=oC-SA-2014-016 http://owncloud.org/security/advisory/?id=oC-SA-2014-017 http://owncloud.org/changelog/ Advisory (Mageia 3): ======================== Updated owncloud packages fix security vulnerabilities: In ownCloud before 5.0.16, due to not sanitising all user provided input the below mentioned ownCloud versions are vulnerable against several XSS attack vectors in the Gallery and ownCloud Core components (CVE-2014-3833). In ownCloud before 5.0.16, due to not verifying whether an user has been granted access to add external storages an authenticated user could even mount external storage (e.g. SMB/FTP/etc.) without permission (CVE-2014-3835). In ownCloud before 5.0.16, due to an improper authorization check in core an attacker with access to at least two user account is able to access the file names of other users (CVE-2014-3838). References: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2014-3833 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2014-3835 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2014-3837 http://owncloud.org/security/advisory/?id=oC-SA-2014-010 http://owncloud.org/security/advisory/?id=oC-SA-2014-012 http://owncloud.org/security/advisory/?id=oC-SA-2014-016 http://owncloud.org/changelog/