Skip to content

Conversation

@acogoluegnes
Copy link
Contributor

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

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
@michaelklishin michaelklishin merged commit b69839e into master Nov 2, 2020
@michaelklishin michaelklishin deleted the rabbitmq-jms-client-135-white-list-stream-message branch November 2, 2020 13:14
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

Successfully merging this pull request may close these issues.

Limit StreamMessage deserialization

3 participants