extplorer package exposes /usr/ (and /etc/extplorer/) directory over HTTP
| Affects | Status | Importance | Assigned to | Milestone | |
|---|---|---|---|---|---|
| extplorer (Ubuntu) |
Confirmed
|
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/
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/
to debian/
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_
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>/
A second, less severe and more theoretical, security vulnerability exists
in the following code:
43 +CONF_FILES=
[...]
61 +D_CONF_
[...]
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://
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/
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/
(e.g., via /usr/lib/
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/
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/
(as explained in the debian/
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@
/
/
Abuse of the second symbolic link is possible due to the package
not creating the /etc/extplorer/
the upstream sources as /usr/share/
(in comparison: a similar file created by the upstream sources,
/usr/
package as also shown below):
root@
ls: cannot access '/etc/extplorer
/
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>/
HTTP/1.1 403 Forbidden
Determine the OS type and version of the host:
$ curl -s 'http://<host>/
NAME="Ubuntu"
VERSION="16.04.6 LTS (Xenial Xerus)"
Retrieve the /etc/ssl/
extplorer/usr symbolic link to /usr/, and then "recursively" following the
/usr/lib/
$ curl -s 'http://<host>/
#
# 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>/
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/
(and enabled through the web server configuration)):
$ curl -s "http://<host>/
<html><body bgcolor=
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+
Ubuntu 14.04 LTS: 2.1.0b6+
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/
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/
3. Edit the web server configuration to deny access to the
/usr/
to subdirectories under /usr/, which means overriding exclusions should
be made to still allow requests to specific lower level directories
under /usr/share/
client requests by the application (e.g., specific directories under
/usr/
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/
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/
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_
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/
are missing as well, could best be added to the installation instructions
(for example in the "Setting-up" section in the debian/
file, which already contains instructions on adding
"Alias /extplorer /usr/share/
REFERENCES
----------
[1] <https:/
[2] <https:/
[3] <https:/
[4] <https:/
[5] <https:/
[6] <https:/
[7] <https:/
[8] <https:/
[9] <https:/
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
| information type: | Private Security → Public Security |
| Changed in extplorer (Ubuntu): | |
| status: | New → Confirmed |

This issue has been assigned CVE-2019-7305