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

[Security] MessagePacket will deserialize arbitrary classes #361

Closed
Gamebuster19901 opened this issue Dec 9, 2020 · 2 comments · Fixed by #368
Closed

[Security] MessagePacket will deserialize arbitrary classes #361

Gamebuster19901 opened this issue Dec 9, 2020 · 2 comments · Fixed by #368
Labels
Milestone

Comments

@Gamebuster19901
Copy link
Contributor

Describe the bug
An attacker can supply any instance of Serializable to MessagePacket, and MessagePacket will happily deserialize it without any checks. This could allow a remote attacker to execute arbitrary code if the classpath contains vulnerable serializeable classes.

final Object dataObject = Serializer.deserialize(objectBytes);

All games which currently use MessagePacket are potentially vulnerable, especially if they have third party libraries on the classpath.

Recommendation
Change de.gurkenlabs.litiengine.util.Serializer to not use java's Serializer. Switch away from using Serializable entirely, and make developers construct objects manually. Do not deserialize untrusted data!

Your System:

  • LITIENGINE version: [e.g. 0.5.0-beta]

Additional Context
Relates to #331

@colin-ife-snyk
Copy link

Hey @Gamebuster19901 do you have a PoC for this?

@steffen-wilke steffen-wilke added this to the v0.5.1-beta milestone Jan 20, 2021
@Gamebuster19901
Copy link
Contributor Author

Hey @Gamebuster19901 do you have a PoC for this?

Unfortunately, I'm not skilled enough to provide a proof of concept. It requires a specific set of vulnerable classes to be on the classpath. It may not be possible to abuse this unless someone adds external libraries to their game which have vulnerable serializable classes.

Just as an example, if Groovy 1.7.0 was on the classpath, then one could abuse CVE-2015-3253.

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

Successfully merging a pull request may close this issue.

3 participants