Not every security software is created equally

Jakub Jóźwicki
3 min readJun 23, 2022

You installed very cool container security tool on every Kubernetes cluster in your enterpise. Some containers crush or hang, REST calls don’t work.

Can we decompile the software to analyze what’s wrong? Yes, provided that we are in EU (see: https://eur-lex.europa.eu/EN/legal-content/summary/computer-programs-legal-protection.html)

Decompilation *

Prior authorisation from the rights-holder is not required where reproduction of the code and translation of its form are essential to obtain information necessary to achieve the interoperability* of a new computer program with other programs.

The following conditions apply:

those acts are performed by the licensee or another person having a right to use a copy of a program;

the information on interoperability has not previously been readily available;

those acts are confined to the parts of the original program which are necessary in order to achieve interoperability.

No error checking in getsockopt easilly visible
Wow, quite heavy disassembling in case the file is big, like Golang or Graal native microservice. See http://udis86.sourceforge.net/manual/libudis86.html.
Emebbed database inside the address space of container processes.
Container security tool works this way that shadows GLIBC system calls but underneath uses the first — matching by name — version of the system call. In case of GLIBC there might be mismatch of parameters and data structures. When the mapping is wrong behavior migh be wrong, undefined, the binary may freeze or crash. Definitely wrong design. How to do it correctly? See: https://blog.fesnel.com/blog/2009/08/25/preloading-with-multiple-symbol-versions/. Also if the ABI of instrumented binary is different than expected by the container security tool bad things can happen. This can happen with hardened GCC used to recompile the whole OS, see: https://docs.oracle.com/en/operating-systems/oracle-linux/6/relnotes6.10/ol6-feature-compiler.html.
The programmer wasn’t aware about EINTR. Under heavy load OS may read less bytes than requested. If only partial content is accepted then control processing may be wrong.
Reading from file without error checking. What about “man read” and EINTR?
Logging is very heavy and definitely slows down execution. It may uncover synchronization bugs in the original program.
No error checking in synchronization.
What about errors from pthread_mutex_lock? Lack of error handling might be pretty serious.
Wow. Is this code MT safe? Have the programmer heard about atomic swap and cmpxchg? https://lwn.net/Articles/847973/. A single sleep would prevent CPU burning.
Many system calls are overriden.
LD_PRELOAD tool communicates with the host agent over socket. There is an overhead.

Summary: poor coding practises, lack of error handling, lack of knowledge about Linux system calls, lack of knowledge about Linux dynamic loader, lack of knowledge about multi-threaded programming. This security tool is going to crash or hang your business applications (in the meantime burning CPU). Direct usage of seccomp/Kubernetes policies (https://en.wikipedia.org/wiki/Seccomp) would be safer.

--

--