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
3 actionable advisories, newest first. Withdrawn advisories and news are excluded. Coverage is partial.
Because of the missing checkLink(String) override in the SecurityManager, students can load libraries and execute arbitrary code. Details Using System.load(String) or System.loadLibrary(String) students can load and execute arbitrary code. Adding this to the security manager (and a translation) should fix the issue: PoC See details. Impact Arbitrary code execution.
Recommended action: Upgrade to 1.11.2 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact This affects all Artemis users who test Java assignments. Ares is not required. Students code that gets automatically tested can run arbitrary code in the container, or arbitrary code on the machine of an assessor in case of manual correction. Patches The problem cannot be resolved easily in Ares itself. Use the Maven Enforcer Plugin as follows: This fails the build if student classes reside in such packages that Ares trusts. Trusted packages added in Ares using @AddTrustedPackage should be added as well. For more information If you have any questions or comments about this advisory: Open a discussion https://github.com/ls1intum/Ares/discussions Open an issue in https://github.com/ls1intum/Ares/issues Email us, see https://github.com/ls1intum/Ares/security/policy References See the assignment of Julius that passes the tests in TUM Artemis course: "Test - Praktikum: Grundlagen der Programmierung (Testkurs für Tutoren) - Security Tests" (if that still exists in 2022). Also see…
Recommended action: Upgrade to 1.8.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact This allows an attacker to create special subclasses of InvocationTargetException that escape the exception sanitization because JUnit extracts the cause in a trusted context before the exception reaches Ares. This means that arbitrary student code can be executed in a trusted context, and that in turn allows disabling Ares and having full control over the system. Patches Update to version 1.7.6 or later. Workarounds Forbid student classes in trusted packages like, e.g., described in https://github.com/ls1intum/Ares/issues/15#issuecomment-996449371 References Are there any links users can visit to find out more? Not that I know of. For more information If you have any questions or comments about this advisory: Open an issue in https://github.com/ls1intum/Ares/issues Email us, see https://github.com/ls1intum/Ares/security/policy Detailed description Using generics, it is possible to throw checked exceptions without a throws clause: <details…
Recommended action: Upgrade to 1.7.6 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.