extplorer package exposes /usr/ (and /etc/extplorer/) directory over HTTP

Bug #1822013 reported by Alex Murray on 2019-03-28
256
This bug affects 1 person
Affects Status Importance Assigned to Milestone
extplorer (Ubuntu)
Undecided
Unassigned

Bug Description

Ubuntu security vulnerability report: "extplorer" package exposes /usr/ (and /etc/extplorer/) directory over HTTP
=================================================================================================================

OVERVIEW
--------

Author: Sander Bos
Author's e-mail address: sbos _at_ sbosnet _dot_ nl
Author's website: www.sbosnet.nl
CVE identifier(s): requested
Date: 2019-03-28
Report version: 1

SUMMARY
-------

The Ubuntu "extplorer" package unintendedly exposes the system's /usr/
directory to the world over HTTP. Authenticating to the eXtplorer
application is not needed to exploit this flaw (but the directory should
not be accessible to authenticated clients either).

In addition, and not needing authentication to the application either,
a less severe vulnerability exists in the package missing a .htaccess
file provided by the upstream application, potentially leading to files
in /etc/extplorer/ (the config/ subdirectory in the application directory)
being accessible over HTTP.

Vulnerability impact types include data leakage, information disclosure,
and potential remote code execution on the eXtplorer server.

Both vulnerabilities exist in a patch file from the package, not in the
upstream code.

Fixes should be implemented as an Ubuntu package update or otherwise
manually by server administrators on systems on which the extplorer
package is installed.

Any CMS projects, web appliances, et cetera that include eXtplorer,
especially when directly based upon the Debian or Ubuntu package, should
also check to see if they are vulnerable as well.

DESCRIPTION
-----------

eXtplorer is a PHP based web file explorer and manager [1].
The application was initially packaged for Debian, and got included in
Ubuntu as well. Currently the package is no longer available in Debian,
but still present in some releases of Ubuntu [2].

The upstream eXtplorer application contains several embedded libraries.
As explained in the debian/README.Debian and debian/README.sources
files in the package, several of those libraries were removed as part
of the package creation and replaced by symbolic links to OS package
versions of those libraries. These symbolic links got created in
the eXtplorer application directory by a Makefile patch file called
debian/patches/debian-changes-2.1.0b6+dfsg-1, which later got renamed
to debian/patches/adds-a-makefile.patch [3].

One of the symbolic links created by the patch file points to the system's
/usr/ directory, to make it possible for the application to access files
under that directory (e.g., library files from dependency packages).
However, by doing so it was overlooked that this symbolic link, i.e.,
the complete /usr/ directory, gets accessible over HTTP. This applies
even outside of the context of eXtplorer: logging into eXtplorer is not
needed to access the directory (which does not mean that it is intended
for users logged into eXtplorer to be able to access the directory;
they shouldn't be able to do so either).

The Makefile file created by the package patch file works by setting
multiple variables including the following (line numbers prepended):

  9 +APP_NAME=extplorer
    [...]
 59 +DESTDIR?=""
 60 +D_APP_DIR?=$(DESTDIR)/usr/share/$(APP_NAME)

Later the file creates symbolic links within the eXtplorer application
directory, with the first one being the problematic symbolic link pointing
to the system's /usr/ directory:

 95 + ##################################################################
 96 + # Link the embedded libraries with their OS packaged replacement #
 97 + ##################################################################
 98 + # Strange behavior of the app
 99 + ln -s ../.. $(D_APP_DIR)/usr

This inadvertently makes the /usr/ directory world-accessible over HTTP,
via <http://<host>/extplorer/usr/>.

A second, less severe and more theoretical, security vulnerability exists
in the following code:

 43 +CONF_FILES=conf.php index.html mimes.php
    [...]
 61 +D_CONF_DIR?=$(DESTDIR)/etc/$(APP_NAME)
    [...]
135 + ##############################################
136 + # Manage the config folder in /etc/extplorer #
137 + ##############################################
138 + @for i in $(CONF_FILES) ; do $(INSTALL) -m $(PHP_RIGHTS) config/$$i $(D_CONF_DIR)/$$i ; done
139 + @ln -s /etc/extplorer $(D_APP_DIR)/config

Here, the "config/" subdirectory present in the upstream eXtplorer
application sources gets replaced by a symbolic link to the
/etc/extplorer/ directory, also being created by the package. However,
an equivalent replacement file for the config/.htaccess file created by
the upstream sources, containing "deny from all" to prevent files in
the directory from being retrieved over HTTP, does not get created in
/etc/extplorer/ by the package.

This could lead to files in /etc/extplorer/ becoming accessible over HTTP,
via <http://host/extplorer/config/<filename>>, where this in fact should
not be possible. Additional web server configuration might be required
however to allow the .htaccess file's contents to take into effect, which
means such instructions could best be added to the package installation
instructions as well (instructions to enable the include/.htaccess file,
which exists in the application directory in the upstream code as well
as in the package, are not provided either by the way).

VULNERABILITY IMPACT
--------------------

With the vulnerabilities listed above the /usr/ system directory, as well
as the /etc/extplorer/ directory, gets accessible over HTTP. Essentially
this means anyone in the world could access files and directories in
those directories over HTTP. It should be explicitly noted that eXtplorer
authentication is not required for this (but accessing these directories
this way is not intended for authenticated eXtplorer users either).

A requirement factor is that following symbolic links should be enabled
in the web server configuration. This is the default for Apache 2.4
though, which in Ubuntu 14.04 LTS and Ubuntu 16.04 LTS by default gets
installed as a dependency of the extplorer package.

File names in /usr/ should be either guessed or known to exist by
the attacker. However, this is not the case if directory listings are
enabled in the web browser (which is not the default in Apache). Thus,
enabled directory listings would make the vulnerability more severe.
For /etc/extplorer/ file names should be guessed or known to exist
both with and without directory listings enabled, due to this directory
containing an index.html file.

The /usr/ directory itself may, and by default does, contain symbolic
links to other directories which in turn can be "recursively"
followed as well. Real world examples of this are symbolic links
in /usr/lib/ssl/ pointing to files and directories in /etc/ssl/, for
example /usr/lib/ssl/private pointing to /etc/ssl/private/ (although
that target directory, which may contain private SSL keys, is most
likely and by default not accessible to the web server due to its file
system permissions).

Generic vulnerability impact types include data leakage, information
disclosure, and potentially remote code execution on the web server by for
example executing PHP, CGI, or other types of executables or executable
scripts present below /usr/ or one of its symbolic links. In case such
scripts take parameters / arguments the executable commands become more
dynamic, possibly leading to arbitrary remote code execution. Also,
directories like /usr/src/ and /usr/local/ might contain site-specific
data which might be of a sensitive nature.

As a particular example of information disclosure, system reconnaissance
can be performed to gain system information then to be used for further
exploitation. Retrievable information includes the installed OS type and
release (e.g., via /usr/lib/os-release), system hardware architecture type
(e.g., via /usr/lib/*-linux-gnu/), install status of packages (that is,
whether or not a package / program is installed / present) and package
versions / patch status of installed packages including the kernel,
glibc, and systemd (e.g., via /usr/share/doc/), and installed (and thus,
possibly enabled) Apache modules (via /usr/lib/apache2/modules).

PROOF OF CONCEPT (PoC)
----------------------

The following steps could be performed to demonstrate the vulnerabilities
on a default installation of Ubuntu 16.04 LTS:

1. Install the "extplorer" package (this will also install the Apache
   web server, via dependencies);

2. add "Alias /extplorer /usr/share/extplorer" to the Apache configuration
   (as explained in the debian/README.Debian file from the extplorer
   package), and reload the Apache configuration;

3. use plain HTTP requests from an HTTP client system (see examples below)
   to abuse the existence of the following symbolic links created by
   the package on the server:

      root@ubuntu1604:~# file /usr/share/extplorer/usr /usr/share/extplorer/config
      /usr/share/extplorer/usr: symbolic link to ../..
      /usr/share/extplorer/config: symbolic link to /etc/extplorer

   Abuse of the second symbolic link is possible due to the package
   not creating the /etc/extplorer/.htaccess file provided by
   the upstream sources as /usr/share/extplorer/config/.htaccess
   (in comparison: a similar file created by the upstream sources,
   /usr/share/extplorer/include/.htaccess, does get created by the
   package as also shown below):

      root@ubuntu1604:~# ls /etc/extplorer/.htaccess /usr/share/extplorer/include/.htaccess
      ls: cannot access '/etc/extplorer/.htaccess': No such file or directory
      /usr/share/extplorer/include/.htaccess

Examples of step 3 for the /usr/ symbolic link vulnerability:

Access the /usr/ directory over HTTP, returning a "403 Forbidden"
HTTP status code indicating presence of the extplorer/usr symbolic link
(i.e., the vulnerability existing) but directory listings disabled on the
web server (in comparison: a "404 Not Found" HTTP status code would be
given if the symbolic link vulnerability did not exist, and a "200 OK"
HTTP status code would be returned in case the symbolic link existed
and directory listings were enabled on the web server):

$ curl -Is 'http://<host>/extplorer/usr/' | head -n 1
HTTP/1.1 403 Forbidden

Determine the OS type and version of the host:

$ curl -s 'http://<host>/extplorer/usr/lib/os-release' | head -n 2
NAME="Ubuntu"
VERSION="16.04.6 LTS (Xenial Xerus)"

Retrieve the /etc/ssl/openssl.cnf file of the host (first following the
extplorer/usr symbolic link to /usr/, and then "recursively" following the
/usr/lib/ssl/openssl.cnf symbolic link pointing to /etc/ssl/openssl.cnf):

$ curl -s 'http://<host>/extplorer/usr/lib/ssl/openssl.cnf' | head -n 4
#
# OpenSSL example configuration file.
# This is mostly being used for generation of certificate requests.
#

Determine the patch status of the installed kernel package, in this
example showing the kernel not being up-to-date with the most recent
package repository version (e.g., the update for USN-3910-1 [4], being
fixed by package version 4.4.0.143.151, is not installed):

$ curl -s 'http://<host>/extplorer/usr/share/doc/linux-generic/changelog.gz' | gzip -d | head -n 1
linux-meta (4.4.0.142.148) xenial; urgency=medium

Example of step 3 for the /etc/extplorer/ vulnerability:

Access the index.html file under /etc/extplorer/ (this file does prevent
directory listings, but would nonetheless not be accessible in case the
/etc/extplorer/.htaccess from the upstream sources would be in place
(and enabled through the web server configuration)):

$ curl -s "http://<host>/extplorer/config/index.html"
<html><body bgcolor="#FFFFFF"></body></html>

VULNERABLE UBUNTU RELEASES / PACKAGE VERSIONS
---------------------------------------------

The vulnerability was introduced in the initial Debian extplorer package
version, version 2.1.0b6+dfsg-1, from 2010 [5]. Consequently, all former
and current Debian and Ubuntu extplorer package versions beginning with
this first package version from 2010 have been vulnerable.

Currently, the following supported Ubuntu versions with their respective
extplorer package versions are vulnerable:

Ubuntu 16.04 LTS: 2.1.0b6+dfsg.3-4+deb7u5ubuntu0.16.04.1
Ubuntu 14.04 LTS: 2.1.0b6+dfsg.3-4+deb7u5build0.14.04.1
Ubuntu 12.04 ESM: 2.1.0b6+dfsg.3-2

(Note: the package version listed for Ubuntu 12.04 ESM is actually the
version from Ubuntu 12.04 LTS; an unchecked assumption is made here that
the version in Ubuntu 12.04 ESM did not change since 12.04 LTS became
12.04 ESM.)

In addition to OS package versions any CMS projects, web appliances,
et cetera that may have eXtplorer included should also check their code.
For instance, eXtplorer can / may be installed as part of Joomla! [6],
and older versions of the TurnKey GNU/Linux File Server appliance
contained eXtplorer as well [7].

PROPOSED FIXES / WORKAROUNDS
----------------------------

Several potential fixes / workarounds are provided here. These should be
implemented as an Ubuntu package update, and / or implemented manually
by server administrators on systems on which the extplorer package
is installed (for example in case the Ubuntu package will not receive
a fix, or in case it will simply get removed from the Ubuntu package
repositories).

In defining on how to fix the /usr/ symbolic link issue, it should
first be investigated for what exact purpose(s) the symbolic link gets
created by the package (i.e., what exact files under extplorer/usr/
are used by eXtplorer). The package does not give a clear indication
about this. It is noteworthy though that the upstream application code
does not contain an extplorer/usr/ subdirectory, which indicates that
the symbolic link was not created as a replacement for such directory
(as is the case with the "extplorer/config" symbolic link for example,
which replaces the upstream extplorer/config/ directory).

The following possibilities for fixes / workarounds can be considered:

1. Remove the Makefile patch lines that create the extplorer/usr
   symbolic link, and create an updated package which also removes such
   existing symbolic link on systems that already have the package
   installed. This may however break certain aspects within the eXtplorer
   application, as the symbolic link was created by the package maintainer
   with a purpose (/var/log/apache2/error.log on the server may give
   clues about breakages).

2. Replace the single, high-level, generic /usr/ symbolic link and
   break it down into multiple, narrowed down, lower level symbolic
   links to the specific directories under /usr/ which are used by the
   application (e.g., directories under /usr/share/javascript/).

3. Edit the web server configuration to deny access to the
   /usr/share/extplorer/usr/ directory. This will then however also apply
   to subdirectories under /usr/, which means overriding exclusions should
   be made to still allow requests to specific lower level directories
   under /usr/share/extplorer/usr/ (i.e., /usr/) which are used in HTTP
   client requests by the application (e.g., specific directories under
   /usr/share/javascript/).

4. Deny following of symbolic links within the application directory
   in the web server configuration (e.g., "Options -FollowSymLinks"
   in Apache). This however will also make lower level subdirectories
   under /usr/share/extplorer/usr/ (i.e., /usr/) inaccessible (leading to
   web server errors), as well as will make requests to extplorer/config
   and extplorer/ftp_tmp (both implemented as symbolic links created by
   the package, replacing equally named directories from the upstream
   sources) fail. The exact implications should thus be considered
   thoroughly, and possibly additional changes should be made to the
   package as well to resolve those implications.

5. Update (re-package) the package based on a more recent upstream source
   version, then obviously without creating the /usr/ symbolic link (and
   implementing an alternative approach for extplorer/usr if that path
   is in fact, and still, needed). A package update is also needed
   since both the Ubuntu 14.04 LTS as well as the Ubuntu 16.04 LTS
   extplorer packages do not work properly out-of-the-box, for example
   due to PHP errors (shown by /var/log/apache2/error.log on the server).
   On Ubuntu 16.04 LTS, which has PHP 7, extplorer/index.php even fails
   right away with a "PHP Fatal warning" due to a call to the undefined
   "set_magic_quotes_runtime()" function (which was removed in PHP 7 [8]).
   Updating the Ubuntu 16.04 LTS package to at least eXtplorer version
   2.1.9, which has PHP 7 support [9], might make the application
   functioning again.

6. Provide an updated package without actual changes but showing a
   clear warning to the server administrator regarding the vulnerability
   of the /usr/ directory being exposed to the world (as well as note
   that in the Makefile patch file). This option could be implemented
   in case the vulnerability turns out not to be fixable on itself.

7. Remove the package from the Ubuntu 14.04 LTS and Ubuntu 16.04 LTS
   package repositories. This option could be implemented in case the
   vulnerability turns out not to be fixable on itself, and would prevent
   new vulnerable installations (but obviously not fix the issue on
   existing installations). It would also make sense since the package
   does not seem to work out-of-the box properly, specifically in the
   case of Ubuntu 16.04 LTS having PHP 7 and the package version of the
   application not having PHP 7 support. Another rationale for this
   option is that the package has already been removed from newer Ubuntu
   releases (as well as newer Debian versions), probably for a reason.

For the issue of .htaccess missing in /etc/extplorer/, the proposed fix
(whether or not combined with a package update based on a more recent
upstream source version) is to let the package (re-)create the file (with
proper permissions). In addition, installation instructions for enabling
the file's content (e.g., "AllowOverride Limit" in Apache), as well as the
same for the extplorer/include/.htaccess file for which such instructions
are missing as well, could best be added to the installation instructions
(for example in the "Setting-up" section in the debian/README.Debian
file, which already contains instructions on adding
"Alias /extplorer /usr/share/extplorer" to the Apache configuration).

REFERENCES
----------

[1] <https://www.extplorer.net/>
[2] <https://packages.ubuntu.com/search?keywords=extplorer>
[3] <https://bazaar.launchpad.net/~ubuntu-branches/debian/sid/extplorer/sid/view/head:/debian/patches/adds-a-makefile.patch> (note: outdated, cloned, repository)
[4] <https://usn.ubuntu.com/3910-1/>
[5] <https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=561872>
[6] <https://extensions.joomla.org/extension/extplorer/>
[7] <https://www.turnkeylinux.org/docs/fileserver>: "[...] previous versions used eXtplorer for the Web interface"
[8] <https://www.php.net/manual/en/function.set-magic-quotes-runtime.php>
[9] <https://www.extplorer.net/news/19>

TIMELINE
========

2019-03-28: initial report version (version 1) sent to the Ubuntu Security Team, along with CVE identifier request

CREDIT
======

Sander Bos discovered, analysed, and reported the vulnerabilities
described in this report. Credits are welcomed in documentation relating
to these vulnerabilities including commit messages, releases, patches,
and security advisories.

CVE References

Alex Murray (alexmurray) wrote :

This issue has been assigned CVE-2019-7305

Alex Murray (alexmurray) on 2019-04-02
information type: Private Security → Public Security
Changed in extplorer (Ubuntu):
status: New → Confirmed
To post a comment you must log in.
This report contains Public Security information  Edit
Everyone can see this security related information.

Other bug subscribers