• LDAP, .setReturningObjFlag(true) and alternatives...

    From Andreas Leitgeb@21:1/5 to All on Fri Oct 13 14:57:50 2023
    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?

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From =?UTF-8?Q?Arne_Vajh=C3=B8j?=@21:1/5 to Andreas Leitgeb on Fri Oct 13 11:15:34 2023
    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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Andreas Leitgeb@21:1/5 to arne@vajhoej.dk on Wed Oct 18 14:15:59 2023
    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.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From =?UTF-8?Q?Arne_Vajh=C3=B8j?=@21:1/5 to Andreas Leitgeb on Wed Oct 18 10:43:17 2023
    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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)