In Opencast before 7.6 and 8.1, using a remember-me cookie with an arbitrary username can cause Opencast to assume proper authentication for that user even if the remember-me cookie was incorrect given that the attacked endpoint also allows anonymous access. This way, an attacker can, for example, fake a remember-me token, assume the identity of the global system administrator and request non-public content from the search service without ever providing any proper authentication. This problem is fixed in Opencast 7.6 and Opencast 8.1

Opencast is an Open Source Lecture Capture & Video Management for Education. Opencast before version 9.10 or 10.6 allows references to local file URLs in ingested media packages, allowing attackers to include local files from Opencast's host machines and making them available via the web interface. Before Opencast 9.10 and 10.6, Opencast would open and include local files during ingests. Attackers could exploit this to include most local files the process has read access to, extracting secrets from the host machine. An attacker would need to have the privileges required to add new media to exploit this. But these are often widely given. The issue has been fixed in Opencast 10.6 and 11.0. You can mitigate this issue by narrowing down the read access Opencast has to files on the file system using UNIX permissions or mandatory access control systems like SELinux. This cannot prevent access to files Opencast needs to read though and we highly recommend updating.

Opencast before 7.6 and 8.1 enables a remember-me cookie based on a hash created from the username, password, and an additional system key. This means that an attacker getting access to a remember-me token for one server can get access to all servers which allow log-in using the same credentials without ever needing the credentials. This problem is fixed in Opencast 7.6 and Opencast 8.1

Opencast before 8.1 stores passwords using the rather outdated and cryptographically insecure MD5 hash algorithm. Furthermore, the hashes are salted using the username instead of a random salt, causing hashes for users with the same username and password to collide which is problematic especially for popular users like the default admin user. This essentially means that for an attacker, it might be feasible to reconstruct a user's password given access to these hashes. Note that attackers needing access to the hashes means that they must gain access to the database in which these are stored first to be able to start cracking the passwords. The problem is addressed in Opencast 8.1 which now uses the modern and much stronger bcrypt password hashing algorithm for storing passwords. Note, that old hashes remain MD5 until the password is updated. For a list of users whose password hashes are stored using MD5, take a look at the /user-utils/users/md5.json REST endpoint.

Opencast before 8.1 and 7.6 allows almost arbitrary identifiers for media packages and elements to be used. This can be problematic for operation and security since such identifiers are sometimes used for file system operations which may lead to an attacker being able to escape working directories and write files to other locations. In addition, Opencast's Id.toString(…) vs Id.compact(…) behavior, the latter trying to mitigate some of the file system problems, can cause errors due to identifier mismatch since an identifier may unintentionally change. This issue is fixed in Opencast 7.6 and 8.1.

Opencast before 8.1 and 7.6 allows unauthorized public access to all media and metadata by default via OAI-PMH. OAI-PMH is part of the default workflow and is activated by default, requiring active user intervention of users to protect media. This leads to users unknowingly handing out public access to events without their knowledge. The problem has been addressed in Opencast 7.6 and 8.1 where the OAI-PMH endpoint is configured to require users with ROLEADMIN by default. In addition to this, Opencast 9 removes the OAI-PMH publication from the default workflow, making the publication a conscious decision users have to make by updating their workflows.

In Opencast before 7.6 and 8.1, users with the role ROLECOURSEADMIN can use the user-utils endpoint to create new users not including the role ROLEADMIN. ROLECOURSEADMIN is a non-standard role in Opencast which is referenced neither in the documentation nor in any code (except for tests) but only in the security configuration. From the name – implying an admin for a specific course – users would never expect that this role allows user creation. This issue is fixed in 7.6 and 8.1 which both ship a new default security configuration.

Opencast is a free, open-source platform to support the management of educational audio and video content. Prior to Opencast 12.5, Opencast's Paella authentication page could be used to redirect to an arbitrary URL for authenticated users. The vulnerability allows attackers to redirect users to sites outside of one's Opencast install, potentially facilitating phishing attacks or other security issues. This issue is fixed in Opencast 12.5 and newer.

Opencast is a free, open-source platform to support the management of educational audio and video content. Prior to Opencast 17.8 and 18.2, the paella would include and render some user inputs (metadata like title, description, etc.) unfiltered and unmodified. The vulnerability allows attackers to inject and malicious HTML and JavaScript in the player, which would then be executed in the browsers of users watching the prepared media. This can then be used to modify the site or to execute actions in the name of logged-in users. To inject malicious metadata, an attacker needs write access to the system. For example, the ability to upload media and modify metadata. This cannot be exploited by unauthenticated users. This issue is fixed in Opencast 17.8 and 18.2.

Opencast is a free, open-source platform to support the management of educational audio and video content. In version 18.0 and versions before 17.7, the protections against path traversal attacks in the UI config module are insufficient, still partially allowing for attacks in very specific cases. The path is checked without checking for the file separator. This could allow attackers access to files within another folder which starts with the same path. This issue has been fixed in versions 17.7 and 18.1. To mitigate this issue, check for folders that start with the same path as the ui-config folder.

Opencast is a free, open-source platform to support the management of educational audio and video content. Prior to Opencast 17.8 and 18.2, in some situations, Opencast's editor may publish a video without notifying the user. This may lead to users accidentally publishing media not meant for publishing, and thus possibly exposing internal media. This risk of this actually impacting someone is very low, though. This can only be triggered by users with write access to an event. They also have to use the editor, which is usually an action taken if they want to publish media and not something users would use on internal media they do not want to publish. Finally, they have to first click on "Save & Publish" before then selecting the "Save" option. Nevertheless, while very unlikely, this can happen. This issue is fixed in Opencast 17.8 and 18.2.