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

Output warning when deserializing object stream #2079

Merged
merged 1 commit into from Oct 6, 2020

Conversation

harawata
Copy link
Member

@harawata harawata commented Oct 3, 2020

We have received another security vulnerability report caused by object stream deserialization.

When all of the following conditions are met, the attacker can trigger RCE (remote code execution).

  1. the user enabled the built-in 2nd level cache [1]
  2. the user did not setup JEP-290 filter
  3. the attacker found a way to modify entries of the private Map field i.e. org.apache.ibatis.cache.impl.PerpetualCache.cache and a valid cache key

We thank clanceyzzz of JD Sprite Team for reporting the issue!

Once this PR gets merged, MyBatis outputs WARN level log message when deserializing object.

As you are using functionality that deserializes object streams, it is recommended to define the JEP-290 serial filter. Please refer to https://docs.oracle.com/pls/topic/lookup?ctx=javase15&id=GUID-8296D8E8-2B93-4B9A-856E-0A65AF9B8C66

Note that:

  • the message is not logged when the JEP-290 filter is already defined
  • the message is logged just once right before the first deserialization

If WARN message is not enough, we can throw an exception instead, but that may surprise users a little bit.

[1] Some of the custom cache implementations also perform deserialization (e.g. mybatis-redis-cache). I plan to look into it later, but the recommended solution is the same i.e. the JEP-290 filter.

@nothingzhl
Copy link
Contributor

if the LookAheadObjectInputStream has been removed , will it affect the functionality of earlier version?like the blacklist.

@harawata
Copy link
Member Author

harawata commented Oct 4, 2020

Thank you for the feedback, @nothingzhl !

This change won't break anything if that is what you mean.
You just need to setup the JEP-290 filter by yourself (using whitelist approach, preferably) to protect your application instead of relying on the built-in blacklist filter.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement Improve a feature or add a new feature security
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

2 participants