What should I do as a user?

Am I affected?

  1. Go to “About” in the left-hand app drawer and look at the app version. If this is 1.9.0 or newer, you are not affected.
  2. Go to “Settings” in the left-hand app drawer and open “General”. See if “Show thumbnails” is enabled. If you don’t have thumbnails enabled (default), you are not affected.
  3. Disable thumbnails by tapping on the switch.

I was affected, which data was exposed?

If you had enabled thumbnails at some point in the past, some or all of your data on a remote might have been accessible under the following conditions:

  • you had RcloneExplorer open browsing a remote (not just in background, or at the remote overview)
  • you where connected to a non-isolated network (like a normal home wifi)
  • you where not connected to a VPN (these tend to make the server inaccessible)

Whether any data was actually accessed can not be determined as there are no server logs kept, and file modification was not possible at any point.

Background

When conducting a security review of the new safdav component, it was discovered that the internal WebDAV server had insufficient protection against unwanted communication from other processes running on the same device. As a consequence, any other http ipc and serving component was investigated.

RcloneExplorer (and its forks) have an option to show thumbnails (image previews for pictures or videos) for content stored on rclone remotes. This option is exposed in the settings menu and disabled by default.

When thumbnails are enabled, rcloneExplorer will start an rclone server every time an rclone remote is browsed. Then a third party image loading library, Glide, will download file contents from this server, process them into thumbnails and manage both caching and displaying of these thumbnails.

However, this rclone server is run over standard HTTP and does not have authentication or authorization to allow Glide to access the images. Additionally, starting with the introduction of the thumbnail feature in RcloneExplorer 1.3.5, this server is accessible

  • from any device connected to the same network
  • or even just from any malicious website accessed from a browser within that network using DNS Rebinding to circumvent the Same Origin Policy (SOP). However, due to SOP, file contents should only be available to the local network.

An exacerbating factor are directory lists “helpfully” provided by rclone, meaning that files could be downloaded by a standard crawler or something as simple as wget.

This was later noticed and seemingly fixed in v1.7.3-beta2/v1.7.4. Unfortunately, the issue was never truly fixed due to a parameter rename and subsequent confusion error.

Root cause analysis

Compare how the newly introduced function overload passes the parameter localhostOnly..

Rclone.java#L397-L399

public Process serve(int protocol, int port, boolean localhostOnly, RemoteItem remote, String servePath) {
     return serve(protocol, port, localhostOnly, null, null, remote, servePath);
}

.. and how this parameter is actually named (and interpreted) there: Rclone.java#L358

public Process serve(int protocol, int port, boolean allowRemoteAccess, 
                     String user, String password, RemoteItem remote, String servePath) {...}

This inversion of parameter semantics is a POLA violation, and it is also quite unfortunate that the fix was seemingly never tested.

Also, serving a remotes content without username or password (see the null/null) is security-sensitive even with localhostOnly = true.

Consequences

  • The overload has been removed because it can not be used securely. Instead, every time an image server is started, a new random access key is generated. Also, the image server has been restricted to localhost.

  • A review of all other rclone.serve(..) dependants was conducted.

    Results

    • Invisible streaming, e.g. when a user selects a streamable (video/audio) file: only the streamed file is served, e.g. no other file or directory list can be accessed. This is consistent with user expectations.

      Due to technical constraints, serving can not be restricted to the app that opened the stream. Since basic authentication might not be supported by the opening app, other options are currently under review.

    • Serving using ⋮ > serve: Access from other devices is disabled by default. No action required. However, allowing remote access might require setting a password in future versions and/or will be pinned to a specific network.

  • A detailed security notice was written

  • A warning notice has been posted to the fork main page linking to the detailed security notice.