search

owncloud / core

:cloud: ownCloud web server core (Files, DAV, etc.)
https://owncloud.com
GNU Affero General Public License v3.0
8.3k stars 2.06k forks source link

Linux Client 1.5.0 Ignores skipUpdateCheck Setting; Lack of Sufficient Disclosure #7198

Closed skavoovie closed 10 years ago

skavoovie commented 10 years ago

Issue: skipUpdateCheck Value Is Ignored

The Linux client phones home with an auto-update check immediately after the sync completes after client start-up, regardless of the skipUpdateCheck boolean value.

I have only tested this on v1.5.0 of the ownCloud Linux client. Other release versions and other Operating System version status is unknown but should be evaluated as well.

(Supporting documentation is provided at the end of this issue report.)

I also think a secondary issue is the obscurity and lack of prevelant notification / disclosure of the auto-update checking. Especially when the documentation admits that auto-updating for the Linux client doesn't actually work.

Recommended Solution

  1. Fix the skipUpdateCheck functionality in the Linux client, and any other OS versions that might also not be obeying this instruction.
  2. Following in the spirit of the marketing and core concepts of ownCloud and its product ("Do you know where your data is?"), ownCloud should re-evaluate the entire auto-update functionality.

Auto-Update / Phone Home functionality should be moved from configuration file obscurity to a prominent location in the "General Settings" of all clients. Ideally, the user should be advised during installation that the client has auto-update functionality that causes it to connect to ownCloud's server, and offer the user to option to either enable or disable that functionality at installation time (disable, notify only, auto-update).

Documented Fix Is Non-Functional

The instructions provided within the documentation to disable auto-update checks / phoning home does not work and has no effect on the client phoning home upon start-up.

Adding the documented argument for disabling auto-update to the user's owncloud.cfg likewise has no effect in preventing the client from phoning home.

Official Documentation

Official Client Documentation ( http://doc.owncloud.org/desktop/1.5/autoupdate.html ) states:

"Since distributions provide their own update tool, ownCloud Client on Linux will not perform any updates on its own. It will, however, check for the latest version and passively notify the user (Settings -> General -> Updates) if an update is available." ... "Since there is no updating functionality, there is no need to remove the check. If you want to disable the check nontheless, open a file called /etc/ownCloud/ownCloud.conf and add the following content:

[General] skipUpdateCheck=true "

However, applying this change to the documented file, /etc/ownCloud/ownCloud.conf, or even trying it in the General section of the individual user's ~/.local/share/data/ownCloud/owncloud.cfg file has no effect, and auto-update checks occur nonetheless.

Supporting Documentation

$ /bin/owncloud -h | head -1
ownCloud version 1.5.0

$ cat /etc/ownCloud/ownCloud.conf
[General]
skipUpdateCheck=true

$ head -5 ~/.local/share/data/ownCloud/owncloud.cfg | grep -v Certificates
[General]
optionalDesktopNotifications=true
monoIcons=false
skipUpdateCheck=true

Launching the client with logging enabled shows the following:

02-13 15:31:32:803 00 client update check to  "https://updates.owncloud.com/client/" 
02-13 15:31:32:819 Sys Info size:  0 
02-13 15:31:32:978 XX slotScheduleFolderSync: folderQueue size:  0 
02-13 15:31:33:124 Loading config:  "/home/user/.local/share/data//ownCloud/owncloud.cfg"  (URL is  "https://[redacted]" ) 
02-13 15:31:33:127 Client is on latest version! 
02-13 15:31:34:773     * event notification  enabled

Monitoring outbound traffic to updates.owncloud.com (50.30.43.96) via iptables and monitoring network traffic both confirm this is actual traffic, not a logging anomaly:

Feb 13 15:31:32 kernel: DST=50.30.43.96 LEN=60 PROTO=TCP SPT=45062 DPT=443
Feb 13 15:31:32 kernel: DST=50.30.43.96 LEN=52 PROTO=TCP SPT=45062 DPT=443
Feb 13 15:31:32 kernel: DST=50.30.43.96 LEN=330 PROTO=TCP SPT=45062 DPT=443
Feb 13 15:31:32 kernel: DST=50.30.43.96 LEN=52 PROTO=TCP SPT=45062 DPT=443
Feb 13 15:31:32 kernel: DST=50.30.43.96 LEN=52 PROTO=TCP SPT=45062 DPT=443
Feb 13 15:31:32 kernel: DST=50.30.43.96 LEN=52 PROTO=TCP SPT=45062 DPT=443
Feb 13 15:31:32 kernel: DST=50.30.43.96 LEN=52 PROTO=TCP SPT=45062 DPT=443
Feb 13 15:31:32 kernel: DST=50.30.43.96 LEN=250 PROTO=TCP SPT=45062 DPT=443
Feb 13 15:31:33 kernel: DST=50.30.43.96 LEN=297 PROTO=TCP SPT=45062 DPT=443
Feb 13 15:31:33 kernel: DST=50.30.43.96 LEN=52 PROTO=TCP SPT=45062 DPT=443
Feb 13 15:31:35 kernel: DST=50.30.43.96 LEN=52 PROTO=TCP SPT=45062 DPT=443
Feb 13 15:31:35 kernel: DST=50.30.43.96 LEN=52 PROTO=TCP SPT=45062 DPT=443
Feb 13 15:31:35 kernel: DST=50.30.43.96 LEN=52 PROTO=TCP SPT=45062 DPT=443

As well as monitoring live network traffic:

Proto Recv-Q Send-Q Local Address           Foreign Address         State       PID/Program name    
tcp        0    278 x.x.x.x:45266        50.30.43.96:443         ESTABLISHED 1352/owncloud

If traffic to the destination ownCloud server is blocked, client logging accurately reflects that the phone home attempt failed:

02-13 15:28:50:844 XX slotScheduleFolderSync: folderQueue size:  0 
02-13 15:28:51:668 00 client update check to  "https://updates.owncloud.com/client/" 
02-13 15:28:51:674 Sys Info size:  0 
02-13 15:28:52:643     * event notification  enabled 
02-13 15:28:57:452 Failed to reach version check url:  "Connection refused"

Somewhat Related Potential Security Issue

One last potential issue is what occurs when DNS-spoofing is used to redirect client update checks to another host. When I tested this, even though the auto-update SSL certificate did not match the updates.owncloud.com domain, no alert was generated to the user if the SSL certificate has been previously trusted for use in syncing. (In my test, I simply redirected the updates.owncloud.com domain to the same server I had ownCloud installed on, which is using a StartCom SSL certificate). The issue was logged, but that is of no help to real world usage scenarios. If the SSL certificate of the destination server wasn't already "trusted" for usage, would an alert have been generated?

From the log output, it appears that the auto-update check is halted since the SSL handshake failed, however the log file also indicates that "event notification" is enabled (not sure if this for auto-updates or for file sync).

From a security perspective, this is probably something that should not be allowed to occur (basically) silently -- users should be immediately warned via a notification due to potential security ramifications.

02-13 16:53:24:368 00 client update check to  "https://updates.owncloud.com/client/" 
02-13 16:53:24:373 Sys Info size:  0 
02-13 16:53:24:458 SSL-Warnings happened for url  "<my_ownCloud_URL_redacted" 
02-13 16:53:24:459 Certs are already known and trusted, Warnings are not valid. 
02-13 16:53:24:531 XX slotScheduleFolderSync: folderQueue size:  0 
02-13 16:53:24:645 Failed to reach version check url:  "SSL handshake failed" 
02-13 16:53:26:331     * event notification  enabled
karlitschek commented 10 years ago

Thanks for the feedback. Can you open this in the mirall repository please where the Client is developed. Thanks