You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
The text was updated successfully, but these errors were encountered:
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.
Quote from https://x-stream.github.io/security.html:
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.
The text was updated successfully, but these errors were encountered: