Open actionable advisories and recorded vendor fixes. This public package view has no inventory attached and cannot establish whether your deployment is affected. A vendor fix never resolves your finding; verify your installed version and the source guidance.
Open advisories
7 actionable advisories, newest first. Withdrawn advisories and news are excluded. Coverage is partial.
Opencast prior to versions 17.6 would incorrectly send the hashed global system account credentials (ie: org.opencastproject.security.digest.user and org.opencastproject.security.digest.pass) when attempting to fetch mediapackage elements included in a mediapackage XML file. A previous CVE prevented many cases where the credentials were inappropriately sent, but not all. The remainder are addressed with this patch. Impact Anyone with ingest permissions could cause Opencast to send its hashed global system account credentials to a url of their choosing. Patches This issue is fixed in Opencast 17.6 If you have any questions or comments about this advisory: - Open an issue in our issue tracker - Email us at security@opencast.org
Recommended action: Upgrade to 17.6 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
In Opencast 2.2.3 and older if user names overlap, the Opencast search service used for publication to the media modules and players will handle the access control incorrectly so that users only need to match part of the user name used for the access restriction. For example, a user with the role ROLEUSER will have access to recordings published only for ROLEUSERX.
Recommended action: Upgrade to 2.2.4 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact Opencast is vulnerable to the Billion laughs attack which allows an attacker to easily execute a (seemingly permanent) denial of service attack, essentially taking down Opencast using a single HTTP request. Consider an XML file (createMediaPackage.xml) like this: Throwing this at Opencast will cause Opencast to parse the XML and expand the Lorem Ipsum about 100 000 times, instantly consuming a huge amount of memory: Additional notes: - You can likely use other endpoints accepting XML (this was just the first one I tried) and depending on how much memory you want to consume, you might want to enlarge the lorem ipsum text. - Opencast's XML parser does limit the expansion to 100 000 times, already limiting the attack. Nevertheless, this can already harm the system. - To exploit this, users need to have ingest privileges, limiting the group of potential attackers Patches The problem has been fixed in Opencast 9.6. Older versions of Opencast are not patched sue to the extent of…
Recommended action: Upgrade to 9.6 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Opencast before version 8.9 and 7.9 disables HTTPS hostname verification of its HTTP client used for a large portion of Opencast's HTTP requests. Hostname verification is an important part when using HTTPS to ensure that the presented certificate is valid for the host. Disabling it can allow for man-in-the-middle attacks. Patches This problem is fixed in Opencast 7.9 and Opencast 8.9 Self-Signed Certificates Please be aware that fixing the problem means that Opencast will not simply accept any self-signed certificates any longer without properly importing them. If you need those, please make sure to import them into the Java key store. Better yet, get a valid certificate e.g. from Let's Encrypt.
Recommended action: Upgrade to 8.9 or 7.9 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact The security configuration in etc/security/mhdefaultorg.xml enables a remember-me cookie based on a hash created from the username, password, and an additional system key. Opencast has hard-coded this system key in the large XML file and never mentions to change this, basically ensuring that all systems use the same 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. For example, a remember-me token obtained from develop.opencast.org can be used on stable.opencast.org without actually knowing the log-in credentials. Such an attack will usually not work on different installations – assuming that safe, unique passwords are used – but it is basically guaranteed to work to get access to all machines of one cluster if a token from one machine is compromised. Patches This problem is fixed in Opencast 7.6 and Opencast 8.1 Workarounds We…
Recommended action: Upgrade to 8.1 or 7.6 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact Users with the role ROLECOURSEADMIN can use the user-utils endpoint to create new users not including the role ROLEADMIN. For example: 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. Patches This issue is fixed in 7.6 and 8.1 which both ship a new default security configuration. Workarounds You can fix this issue by removing all instances of ROLECOURSEADMIN in your organization's security configuration (etc/security/mhdefaultorg.xml by default). For more information If you have any questions or comments about this advisory: - Open an issue in opencast/opencast - For security-relevant information, email us at security@opencast.org
Recommended action: Upgrade to 8.1 or 7.6 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact 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. Patches This problem is fixed in Opencast 7.6 and Opencast 8.1 Workarounds As a workaround for older, unpatched versions, disabling remember-me cookies in etc/security/mhdefaultorg.xml will mitigate the problem but will obviously also disable this feature without obvious indication. To deactivate this, remove the following line from the security configuration: References - Remember-me cookie in the security configuration file For more information If you have any questions or comments about this advisory: - Open an issue in…
Recommended action: Upgrade to 8.1 or 7.6 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.