commons-issues mailing list archives

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

    [ 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)

Mime
View raw message