Thanks Sean,
You've gone to some trouble to answer my question, which demonstrates
you have considered it.
I donate some time to help maintain Apache River, derived from Sun's
Jini. Once Jini depended on RMI, today, not so much, it still has some
dependencies on some RMI interfaces, but doesn't utilise JRMP although
it provides some backward compatibilty enable it.
But my point is, we heavily utilise java Serialization, and have an
independant implementation of a subset of Java Serialization
(originating from Apache Harmony). We do this for security as we use an
annotated serialization constructor. Serial form is unchanged, we have
Serializers for commonly used java library objects, for example, we have
a "PermissionSerializer", but we don't have a
"PermissionCollectionSerializer" or "PermissionsSerializer" (for
java.security.Permissions). Incidentally, we have found we do not need
the ability to serialize circular object graphs. Throwable is an
object that has a circular object graph, but that circular object graph
can be linked up after deserialization.
Permission implementing Serializable is probably not too much of a
threat, as these objects are effectively immutable after lazy
initialization.
ProtectionDomain calls java.security.Permissions::setReadOnly during
it's construction.
ProtectionDomain::getPermissions returns internal
java.security.Permissions. If this is serialized, then the readOnly
internal state can be written to as the internal object references are
accessible from within the stream.
Admitedly, the attacker would already need to have some privilege, to
have access to a ProtectionDomain, so it's a path of privilege
escallation. I'm not talking about gadget attacks and deserialization
of untrusted data, I'm talking about breaking encapsulation.
Even though we are heavily dependant on Java Serialization, we are very
careful when we implement it, and avoid implementing it when possible.
Hindsight is 20:20, but given we are now seeing some Java SE backward
compatibility breakages, perhaps it might be worth considering breaking
serialization. I don't mean we need to necessarily break object serial
form, but making the Java serialization API explicit with subset of
existing api features, that makes long term maintenace and security less
of a burden and removing support for Serialization of some objects,
where it is seldom used, perhaps using a JEP that requests developers to
consider which library objects actually need to be serializable.
Something we do in our Java Serialization API is require that mutable
deserialized objects are defensively copied during object construction
(serial fields are deserialized before an object is constructed, the
deserialized fields are accessible via a parameter passed in during
construction. We have tools that assist developers to check
deserialized Java Collections contain the expected object types for
example, so during object construction the developer has to replace the
Collection with a new instance and copy the contents to the new
Collection after checking the type of each object contained therein.
Also we don't actually serialize Java Collections, we have standard
serial forms for List, Set and Map, so these serial forms are equal,
similar to the List, Set and Map contracts. By doing this, Collections
don't actually need to implement Serializable at all, as a Serializer
becomes responsible for their serialization. This also means that all
Collections must be accessed by interfaces, rather than implementation
classes, so the deserialization constructor, must defensively copy them
into their preferred Collection instance. It's a bit like dependency
injection.
I know it would take time, and there would be some pain, but long term
it would save a lot of maintenance developer time.
Regards,
Peter.
On 17/08/2019 12:50 AM, Sean Mullan wrote:
On 8/15/19 8:18 PM, Peter Firmstone wrote:
Hi Roger,
+1 for writeReplace
Personally I'd like to see some security classes break backward
compatibility and remove support for serialization as it allows
someone to get references to internal objects, especially since these
classes are cached by the JVM. Which makes
PermissionCollection.setReadOnly() very easy to bypass, by adding
permissions to internal collections once you have a reference to them.
Does anyone have any use cases for serializing these objects?
These objects are easy to re-create by sending or recieving and
parsing strings, because they are built from text based policy files,
and when you do that, you are validating input, so I never did fully
understand why they were made serializable.
This is briefly explained on page 61 in the "Inside Java 2 Platform
Security" book [1]:
"The Permission class implements two interfaces: java.security.Guard
and java.io.Serializable. For the latter, the intention is that
Permission objects may be transported to remote machines, such as via
Remote Method Invocation (RMI), and thus a Serializable representation
is useful."
The Permission class was introduced in Java SE 1.2 so there were
different motivations back then :)
--Sean
[1] https://www.oracle.com/technetwork/java/javaee/index-141918.html
