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

Limit StreamMessage deserialization #135

Closed
acogoluegnes opened this issue Nov 2, 2020 · 0 comments · Fixed by #136
Closed

Limit StreamMessage deserialization #135

acogoluegnes opened this issue Nov 2, 2020 · 0 comments · Fixed by #136
Assignees
Milestone

Comments

@acogoluegnes
Copy link
Contributor

@acogoluegnes acogoluegnes commented Nov 2, 2020

StreamMessage should use the same "white list" mechanism as ObjectMessage to avoid some arbitrary code execution on deserialization.

Even though StreamMessage is supposed to handle only primitive types, it is still to possible to send a message that contains an arbitrary serializable instance. The consuming application application may then execute code from this class on deserialization.

The fix consists in using the list of trusted packages that can be set at the connection factory level.

@acogoluegnes acogoluegnes added this to the 2.2.0 milestone Nov 2, 2020
@acogoluegnes acogoluegnes self-assigned this Nov 2, 2020
acogoluegnes added a commit that referenced this issue Nov 2, 2020
StreamMessage now uses the same "white list" mechanism as
ObjectMessage to avoid some arbitrary code execution on deserialization.

Even though StreamMessage is supposed to handle only primitive types,
it is still to possible to send a message that contains an arbitrary
serializable instance. The consuming application application may
then execute code from this class on deserialization.

The fix consists in using the list of trusted packages that can be
set at the connection factory level.

Fixes #135
acogoluegnes added a commit that referenced this issue Nov 3, 2020
StreamMessage now uses the same "white list" mechanism as
ObjectMessage to avoid some arbitrary code execution on deserialization.

Even though StreamMessage is supposed to handle only primitive types,
it is still to possible to send a message that contains an arbitrary
serializable instance. The consuming application application may
then execute code from this class on deserialization.

The fix consists in using the list of trusted packages that can be
set at the connection factory level.

Fixes #135

(cherry picked from commit f647e5d)
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

1 participant