commons-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Alex Herbert (Jira)" <>
Subject [jira] [Commented] (RNG-120) Fix security issues in serialization code for Random instances
Date Tue, 01 Oct 2019 16:11:00 GMT


Alex Herbert commented on RNG-120:

{quote}But how can one be sure?
I suppose you can be sure if you created the serialized form and know it could not have been
{quote}Doesn't your fixes imply that one should always perform validation
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)?

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:
>             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|]
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

View raw message