I've stumbled over java code, that does an LDAP query, and
sets flag .setReturningObjFlag(true) on the searchControl object.

According to some ressources, like e.g.
https://app.deepsource.com/directory/analyzers/java/issues/JAVA-S1026
this should be avoided, unless the LDAP server and its
data is really trusted.

I'd be curious, what would be the alternatives, under the assumption,
that there are indeed serialized Objects stored in LDAP in whose value
I'm really interested, and if I then didn't want to trust the server
to always return data for the expected objects.

According to description of setReturningObjFlag(): if this flag
is false "... only the name and class of the object is returned",
which to me sounds like I won't get the serialized data.

Do I misunderstand it, or is there no third option besides:
- trust the LDAP-server and have received data immediately deserialized
- not trust the LDAP-server and just not get the data at all.

Is there, maybe, a way to restrict the classes to a whitelist
of classes that it may deserialize, and get an exception on
any attempt to pull in any other class, before that other class
is even initialized?

Is there, maybe, a way to just retrieve the serialized stream and
scrape the relevant info without full deserialization?

On 10/13/2023 10:57 AM, Andreas Leitgeb wrote:
> I've stumbled over java code, that does an LDAP query, and
> sets flag .setReturningObjFlag(true) on the searchControl object.
>
> According to some ressources, like e.g.
> https://app.deepsource.com/directory/analyzers/java/issues/JAVA-S1026
> this should be avoided, unless the LDAP server and its
> data is really trusted.
>
> I'd be curious, what would be the alternatives, under the assumption,
> that there are indeed serialized Objects stored in LDAP in whose value
> I'm really interested, and if I then didn't want to trust the server
> to always return data for the expected objects.
>
> According to description of setReturningObjFlag(): if this flag
> is false "... only the name and class of the object is returned",
> which to me sounds like I won't get the serialized data.
>
> Do I misunderstand it, or is there no third option besides:
> - trust the LDAP-server and have received data immediately deserialized
> - not trust the LDAP-server and just not get the data at all.
>
> Is there, maybe, a way to restrict the classes to a whitelist
> of classes that it may deserialize, and get an exception on
> any attempt to pull in any other class, before that other class
> is even initialized?
>
> Is there, maybe, a way to just retrieve the serialized stream and
> scrape the relevant info without full deserialization?

Java deserialization of objects is known to be potential
security problem:
- use all memory
- execute code in readObject method

But I assume your LDAP service is somewhat trusted (as it
its usually provides authentication & authorization!).

So depending on security level you can:
* decide that you trust LDAP and continue to automatic deserialize
* continue to automatic deserialize but find a way to plugin
a deserialization filter (assuming you are on Java 9+ where that
was introduced)
* drop the automatic deserialize and redesign the data transfer
in some way:
- instead of Java object have either JSON or XML and
do a DOM tree parse not a binding to get the data over
in a Java object
- move the info from LDAP to somewhere else like database

Arne

Arne Vajhøj <arne@vajhoej.dk> wrote:
> On 10/13/2023 10:57 AM, Andreas Leitgeb wrote:
>> https://app.deepsource.com/directory/analyzers/java/issues/JAVA-S1026
>> Do I misunderstand it, or is there no third option besides:
>> - trust the LDAP-server and have received data immediately deserialized
>> - not trust the LDAP-server and just not get the data at all.
>>
>> Is there, maybe, a way to restrict the classes to a whitelist
>> of classes that it may deserialize,
>>
>> Is there, maybe, a way to just retrieve the serialized stream and
>> scrape the relevant info without full deserialization?
>
> Java deserialization of objects is known to be potential
> security problem:
> - use all memory
> - execute code in readObject method

Yes, the root-cause of this topic...

> But I assume your LDAP service is somewhat trusted (as it
> its usually provides authentication & authorization!).

That is correct. This is primarily for learning.
The LDAP server and in particular the element that jndi
wants to eventually deserialize is trusted. But what if
it weren't? ;-)

> So depending on security level you can:
> * decide that you trust LDAP and continue to automatic deserialize
yes, sure.

> * continue to automatic deserialize but find a way to plugin
> a deserialization filter (assuming you are on Java 9+ where that
> was introduced)

Ah, good to know - for future.

> * drop the automatic deserialize and redesign the data transfer
> in some way:
> - instead of Java object have either JSON or XML and
> do a DOM tree parse not a binding to get the data over
> in a Java object
> - move the info from LDAP to somewhere else like database

Not sure if I understand this correctly... is this a way to retrieve
the same data that is already stored in LDAP but in alternative formats,
or do you mean that the data in LDAP needs to be stored in those other
formats(e.g. json) for that to work?

PS: sorry for my late answer... the other problem about slrn and c.l.j.p
strikes again, and I needed to dig out that other machine again, to be
able to check for followups and answer.

On 10/18/2023 10:15 AM, Andreas Leitgeb wrote:
> Arne Vajhøj <arne@vajhoej.dk> wrote:
>> So depending on security level you can:
>> * decide that you trust LDAP and continue to automatic deserialize
> yes, sure.
>
>> * continue to automatic deserialize but find a way to plugin
>> a deserialization filter (assuming you are on Java 9+ where that
>> was introduced)
>
> Ah, good to know - for future.

Java 9+ docs should have the details.

The short version is:

-Djdk.serialFilter=mypackage.MyClass

which should only allow this specific class to be deserialized.

(there are a ton of other options)

>> * drop the automatic deserialize and redesign the data transfer
>> in some way:
>> - instead of Java object have either JSON or XML and
>> do a DOM tree parse not a binding to get the data over
>> in a Java object
>> - move the info from LDAP to somewhere else like database
>
> Not sure if I understand this correctly... is this a way to retrieve
> the same data that is already stored in LDAP but in alternative formats,
> or do you mean that the data in LDAP needs to be stored in those other
> formats(e.g. json) for that to work?

I am talking about being stored in a different format.

It could solve the deserialization security problem.

And I think there would be other benefits.

Serialized Java objects and what happen if the class
definition changes later is a big topic.

Arne