[Security] Bump xstream from 1.4.13 to 1.4.15

[dependabot-preview]

Bumps xstream from 1.4.13 to 1.4.15. This update includes security fixes.

Vulnerabilities fixed

Sourced from The GitHub Security Advisory Database.

A Server-Side Forgery Request can be activated unmarshalling with XStream

Impact

The vulnerability may allow a remote attacker to request data from internal resources that are not publicly available only by manipulating the processed input stream.

Patches

If you rely on XStream's default blacklist of the Security Framework, you will have to use at least version 1.4.15.

Workarounds

The reported vulnerability does not exist running Java 15 or higher.

No user is affected, who followed the recommendation to setup XStream's Security Framework with a whitelist! Anyone relying on XStream's default blacklist can immediately switch to a whilelist for the allowed types to avoid the vulnerability.

Users of XStream 1.4.14 or below who still insist to use XStream default blacklist - despite that clear recommendation - can use a workaround depending on their version in use.

Users of XStream 1.4.14 can simply add two lines to XStream's setup code:

xstream.denyTypes(new String[]{ "jdk.nashorn.internal.objects.NativeString" });
xstream.denyTypesByRegExp(new String[]{ ".*\\.ReadAllStream\\$FileStream" });

Users of XStream 1.4.14 to 1.4.13 can simply add three lines to XStream's setup code:

Affected versions: < 1.4.15

Sourced from The GitHub Security Advisory Database.

XStream is vulnerable to an Arbitrary File Deletion on the local host when unmarshalling

Impact

The vulnerability may allow a remote attacker to delete arbitrary know files on the host as log as the executing process has sufficient rights only by manipulating the processed input stream.

Patches

If you rely on XStream's default blacklist of the Security Framework, you will have to use at least version 1.4.15.

Workarounds

The reported vulnerability does only exist with a JAX-WS runtime on the classpath.

No user is affected, who followed the recommendation to setup XStream's Security Framework with a whitelist! Anyone relying on XStream's default blacklist can immediately switch to a whilelist for the allowed types to avoid the vulnerability.

Users of XStream 1.4.14 or below who still insist to use XStream default blacklist - despite that clear recommendation - can use a workaround depending on their version in use.

Users of XStream 1.4.14 can simply add two lines to XStream's setup code:

xstream.denyTypes(new String[]{ "jdk.nashorn.internal.objects.NativeString" });
xstream.denyTypesByRegExp(new String[]{ ".*\\.ReadAllStream\\$FileStream" });

Users of XStream 1.4.14 to 1.4.13 can simply add three lines to XStream's setup code:

Affected versions: < 1.4.15

Sourced from The GitHub Security Advisory Database.

XStream can be used for Remote Code Execution

Impact

The vulnerability may allow a remote attacker to run arbitrary shell commands only by manipulating the processed input stream.

Patches

If you rely on XStream's default blacklist of the Security Framework, you will have to use at least version 1.4.14.

Workarounds

No user is affected, who followed the recommendation to setup XStream's Security Framework with a whitelist! Anyone relying on XStream's default blacklist can immediately switch to a whilelist for the allowed types to avoid the vulnerability.

Users of XStream 1.4.13 or below who still want to use XStream default blacklist can use a workaround depending on their version in use.

Users of XStream 1.4.13 can simply add two lines to XStream's setup code:

xstream.denyTypes(new String[]{ "javax.imageio.ImageIO$ContainsFilter" });
xstream.denyTypes(new Class[]{ java.lang.ProcessBuilder.class });

Users of XStream 1.4.12 to 1.4.7 who want to use XStream with a black list will have to setup such a list from scratch and deny at least the following types: javax.imageio.ImageIO$ContainsFilter, java.beans.EventHandler, java.lang.ProcessBuilder, java.lang.Void and void.

xstream.denyTypes(new String[]{ "javax.imageio.ImageIO$ContainsFilter" });
xstream.denyTypes(new Class[]{ java.lang.ProcessBuilder.class, java.beans.EventHandler.class, java.lang.ProcessBuilder.class, java.lang.Void.class, void.class });
</tr></table> ... (truncated)
Affected versions: <= 1.4.13

Commits

• See full diff in compare view

Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.

---

Dependabot commands and options

You can trigger Dependabot actions by commenting on this PR:

• @dependabot rebase will rebase this PR
• @dependabot recreate will recreate this PR, overwriting any edits that have been made to it
• @dependabot merge will merge this PR after your CI passes on it
• @dependabot squash and merge will squash and merge this PR after your CI passes on it
• @dependabot cancel merge will cancel a previously requested merge and block automerging
• @dependabot reopen will reopen this PR if it is closed
• @dependabot close will close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually
• @dependabot ignore this major version will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself)
• @dependabot ignore this minor version will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself)
• @dependabot ignore this dependency will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)
• @dependabot use these labels will set the current labels as the default for future PRs for this repo and language
• @dependabot use these reviewers will set the current reviewers as the default for future PRs for this repo and language
• @dependabot use these assignees will set the current assignees as the default for future PRs for this repo and language
• @dependabot use this milestone will set the current milestone as the default for future PRs for this repo and language
• @dependabot badge me will comment on this PR with code to add a "Dependabot enabled" badge to your readme

Additionally, you can set the following in your Dependabot dashboard:

• Update frequency (including time of day and day of week)
• Pull request limits (per update run and/or open at any time)
• Out-of-range updates (receive only lockfile updates, if desired)
• Security updates (receive only security updates, if desired)

[dependabot-preview]

Superseded by #35.