Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Replace XStream with human-editable file format and structure #726

Open
TheAssassin opened this issue Apr 26, 2024 · 1 comment
Open

Replace XStream with human-editable file format and structure #726

TheAssassin opened this issue Apr 26, 2024 · 1 comment

Comments

@TheAssassin
Copy link
Contributor

Quote from https://x-stream.github.io/security.html:

Stream is designed to be an easy to use library. It takes its main task seriously: converting Java objects to XML, and XML to Java objects. As a result, it is possible to create an instance of XStream with the default constructor, call a method to convert an object into XML, then call another method to turn the XML back into an equivalent Java object. By design, there are few limits to the type of objects XStream can handle.

This flexibility comes at a price. XStream applies various techniques under the hood to ensure it is able to handle all types of objects. This includes using undocumented Java features and reflection. The XML generated by XStream includes all information required to build objects of almost any type. This introduces a potential security problem.

The provided XML data is used by XStream to unmarshal Java objects. This data can be manipulated by injecting the XML representation of other objects, that were not present at marshalling time. An attacker could take advantage of this to access private data, delete local files, execute arbitrary code or shell commands in the context of the server running the XStream process or cause a denial of service by crashing the application or manage to enter an endless loop consuming 100% of CPU cycles.

TL;DR: it's not a good idea to use XStream. Especially given the fact that people download(!) those objects from the Internet. XStream has had lots of RCE and other critical vulnerabilities. It may not be a big deal when just used locally, but the way VisiCut downloads the configuration entirely is.

Other than that, I'm not a fan of not being able to edit the configuration manually (or at least having a hard time doing so). Often, only a small change is required. Or one wants to copy an entire file and adjust it a bit for a new format.

I think it's worth and advisable to replace this setup entirely with a custom configuration loading system.

@mgmax
Copy link
Collaborator

mgmax commented Apr 27, 2024

Given the amount of workarounds we needed to keep XStream working (--add-opens and friends), I'd be more than happy to get it replaced. Feel free to propose something.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants