keylog module causes deadlock when trying dynamically load c-shared poseidon on older glibc

[paul-axe]

Hi.

I faced an issue when tried to load poseidon as c-shared library in an obsolete evnironment and it resulted in a deadlock. After the debugging session it's turned out that the issue is because of keylog module, and particularly in user.Curent() of os/user . The issue is most likely because the call is triggered from the library contrustror, which loads keylog module which creates an NewKeyLog instance in the init stage: https://github.com/MythicAgents/poseidon/blob/8f6c1e7fd5ab027e40da4a485ce33e8a95858f82/Payload_Type/poseidon/poseidon/agent_code/keylog/keystate/keystate.go#L13-L16 https://github.com/MythicAgents/poseidon/blob/8f6c1e7fd5ab027e40da4a485ce33e8a95858f82/Payload_Type/poseidon/poseidon/agent_code/keylog/keystate/keystate.go#L108-L109 As far as I understand the problem is related to a multithreaded loading of the dynamic library (user.Current loads libc to execute getpwuid_r) while another thread holds the dlopen lock for loading poseidon library. It also seems that problem is fixed/mitigated somehow in the libc 2.35. The problem also doesnt appear when loading poseidon using LD_PRELOAD.

Steps to reproduce:

1. Compile poseidon as c-shared library
2. Try to load it with libc <= 2.34 (any ubuntu before 22.04 release)

$ docker run -ti -v $(pwd):/app python:2 python2 -c '__import__("ctypes").CDLL("/app/poseidon.so")'
debug string: true

3. You've got a deadlock

Possible solution

Probably moving the call of NewKeyLog from init/constructor stage to a direct call from outside should fix the issue