App - System

using this command inside the web ssh :
$(ldd /bin/ls|grep libc.so|cut -d’ ’ -f3)
and particularly $(ldd ch44|grep libc.so|cut -d’ ’ -f3)
show me that the binaries are suppose to use glibc version 2.27 (dynamic dependency)
But when running the binary(both ssh and remote TCP/netcat connection)-
it turns out it actually loads a version >= 2.29 (I know it by the error message of a modern mitigation that came up only since version 2.29 - "double free detected in tcache 2")

how is that possible ? How could I know the glibc version without getting hit by the error message ?

I am far from being an expert on this topic, but, it seems that your assumption "it turns out it actually loads a version >= 2.29 (I know it by the error message of a modern mitigation that came up only since version 2.29 - "double free detected in tcache 2")" is wrong.

Indeed, it seems that this patch (https://sourceware.org/legacy-ml/libc-stable/2018-12/msg00008.html) has been backported in this particular glibc 2.27 version.

You can check it by executing the strings command on the libc.so of the remote machine, you will find the string "double free detected in tcache 2" and also that the version is the glibc 2.27.

I suppose you already know the following trick, but even if ldd displays that the the binary is supposed to run with the glibc version 2.27, if the binary is launched with something like ’LD_PRELOAD=path_to_custom_libc ./path_to_custom_ld ./ch44’ then the glibc 2.27 will not be used.