YARN: restrict leveldb conf store log deserialization to known types#8612
Open
nishat-06 wants to merge 1 commit into
Open
YARN: restrict leveldb conf store log deserialization to known types#8612nishat-06 wants to merge 1 commit into
nishat-06 wants to merge 1 commit into
Conversation
|
🎊 +1 overall
This message was automatically generated. |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Description of PR
LeveldbConfigurationStore.deserLogMutationsreads the capacity scheduler configuration log back with a bareObjectInputStream, so whatever sits under the leveldblogkey decides whichSerializabletypes the RM constructs during recovery.ZKConfigurationStore.deserializeObjectalready fences the identicalLinkedList<LogMutation>graph behind aValidatingObjectInputStreamallowlist, andTestZKConfigurationStore.testDeserializationIsNotVulnerablepins that with a ysoserial payload, but the leveldb store never got either. This applies the sameaccept()list at the point the bytes are turned back into objects.ConfigurationUpdateAssembler.constructKeyValueConfUpdatebuilds the updates map withnew HashMap<>(), soLinkedList,LogMutation,HashMapandStringcover a real configuration log and valid stores still load unchanged.How was this patch tested?
Added
testDeserializationIsNotVulnerabletoTestLeveldbConfigurationStore, alongside the existing ZK one. It plants a list holding a type that is not part of a configuration log and asserts the read is rejected and the type is never constructed. Against the unpatched store the payload'sreadObjectruns and no exception is raised; with the patch it fails withInvalidClassException.mvn compile/test-compileandcheckstyle:checkare clean for both files on JDK 17. I could not execute the leveldb suite locally,leveldbjniships no arm64 native and the existing tests in that class already fail the same way on this machine, so I am relying on CI for the run.For code changes:
LICENSE,LICENSE-binary,NOTICE-binaryfiles?AI Tooling
If an AI tool was used:
where is the name of the AI tool used.
https://www.apache.org/legal/generative-tooling.html