Jeśli przeczytacie ten opis to może się wydawać że w sumie wszystko OK. No może poza tym zdaniem:
We recommend that customers who run Java applications in containers, and use either the hotpatch or Hotdog, update to the latest versions of the software immediately.
Jeśli z kolei zobaczymy materiał źródłowy, okaże się, że nie jest tak różowo:
Containers can escape regardless of whether they run Java applications, or whether their underlying host runs Bottlerocket, AWS’s hardened Linux distribution for containers. Containers running with user namespaces or as a non-root user are affected as well. Unit 42 assigned CVE-2021-3100, CVE-2021-3101, CVE-2022-0070 and CVE-2022-0071 to track the vulnerabilities.
Co spowodowało wystąpienie podatności? „Dynamiczna” łatka AWS na podatność log4shell analizuje procesy o nazwie java i próbuje je łatać. Tylko że samo „łatanie” nie ma zapewnionej odpowiedniej konteneryzacji. Można więc podstawić lewy proces o nazwie „java” i wykorzystać go do odpalenia swojego kodu (wyskoczenia z kontenera):
AWS’s hot patch solutions continuously search for Java processes and patch them against Log4Shell on the fly. Any process running a binary named “java“ – inside or outside of a container – is considered a candidate for the hot patch.
To patch Java processes inside containers, the hot patch solutions invoke certain container binaries. For example, they run the container’s „java” binary twice: once to retrieve the Java version, and again to inject the hot patch. The issue was that they invoked container binaries without properly containerizing them. That is, the new processes would run without the limitations normally applied to container processes.
Badacze pokazują dwa scenariusze wykorzystania podatności: bezwiedne uruchomienie już zainfekowanego kontenera oraz zaatakowanie już działającego kontenera (i podstawienie odpowiedniego procesu).
Ilustracja filmowa:
Jak się załatać? Dla pewności zerknijcie na sekcję Mitigation w oryginalnym badaniu.
