[
https://issues.apache.org/jira/browse/RNG-120?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16942109#comment-16942109
]
Alex Herbert commented on RNG-120:
----------------------------------
{quote}But how can one be sure?
{quote}
I suppose you can be sure if you created the serialized form and know it could
not have been altered.
{quote}Doesn't your fixes imply that one should always perform validation
{quote}
It seems to be the case that serialization should not be done unchecked if you
really want to be safe. However added a checking guard in front of
ObjectInputStream is very easy. Perhaps this is why serialization is
out-of-favour nowadays.
{quote}that your SerializableTestObject would fail to be loaded if the data
were actually coming from an untrusted source (i.e. read from the network)?
{quote}
Yes.
The class loader has to be able to find the class. In this case the custom
class would not be found and ClassNotFoundException would be raised when
deserializing.
I did originally write the test using a String instead. However that has custom
deserialization and the test did not work (I found a note in the String.class
source code about custom serialization). So I created a dummy class. I've just
tried it with SerializableTestObject replaced with ArrayList and it still works
as expected.
The article states to the effect that the attacker has to have a guess at what
classes could be on the classpath of the server that will deserialise data. I
assume it wisely chooses to not propose good candidates for an attack.
The likelihood of this being a problem is low. It would require that:
# a system is reconstructing a RNG, specifically the JDKRandom which is not
recommended, using data sent to it in byte[] form and loaded via the
RestoreableUniformRandomProvider. That data may have been created with
malicious intent.
# a system is using JDKRandomBridge and restoring it from a serialized form
that is from an external source and may have been created with malicious intent.
However I do not see a problem with fixing the code. All the existing
functionality is maintained and serialization is made safer.
> Fix security issues in serialization code for Random instances
> --------------------------------------------------------------
>
> Key: RNG-120
> URL: https://issues.apache.org/jira/browse/RNG-120
> Project: Commons RNG
> Issue Type: Improvement
> Components: core, simple
> Affects Versions: 1.3
> Reporter: Alex Herbert
> Assignee: Alex Herbert
> Priority: Minor
> Time Spent: 20m
> Remaining Estimate: 0h
>
> SonarCloud has highlighted security issues in the use of serialization to
> save and restore the state of java.util.Random instances.
> When reading objects using ObjectInputStream.readObject() the class is first
> identified and the private readObject() method of the class type is executed
> (if it is present). If the class is a malicious class then potentially
> malicious code can be executed.
> h2. JDKRandom
> Uses serialisation to save the {{java.util.Random}} instance to the
> RandomProviderState.
> The code requires that {{java.util.Random}} is read using
> ObjectInputStream.readObject(). To ensure the code only allows
> {{java.util.Random}} to be read the code can adapt the
> [ValidatingObjectInputStream|https://commons.apache.org/proper/commons-io/javadocs/api-2.6/org/apache/commons/io/serialization/ValidatingObjectInputStream.html]
> idea from Commons IO to prevent malicious code execution.
> h2. JDKRandomBridge
> This writes and reads a byte[] using the writeObject and readObject methods
> of ObjectOutput/InputStream. To avoid use of readObject() the code can be
> refactored to write the byte[] using the write(byte[]) method of
> ObjectOutputStream and the readFully(byte[]) method of ObjectInputStream.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
