Artemis Java Test Sandbox versions less than 1.7.6 are vulnerable to a sandbox escape when an attacker crafts a special subclass of InvocationTargetException. An attacker can abuse this issue to execute arbitrary Java when a victim executes the supposedly sandboxed code.

Affected: Maven: de.tum.in.ase:artemis-java-test-sandbox

### 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> <summary>ThrowWithoutThrowsHelper</summary>

```java public class ThrowWithoutThrowsHelper<X extends Throwable> { private final X throwable;

private ThrowWithoutThrowsHelper(X throwable) { this.throwable = throwable; }

private <R> R throwWithThrows() throws X { throw throwable; }

public static <R> R throwWithoutThrows(Throwable throwable) { ThrowWithoutThrowsHelper<?> helper = new ThrowWithoutThrowsHelper<Throwable>(throwable);…