Czym jest Stack Clash? Jest to eksploatacja błędu w zarządzaniu pamięci oparta na dość starej (12 letniej) technice. Dotyka ona kilku systemów operacyjnych: Linuksa, OpenBSD, NetBSD, FreeBSD oraz Solarisa dla architektury i386 oraz amd64. Technika ta może zostać wykorzystana przez atakujących do naruszenia bezpieczeństwa pamięci oraz wykonania dowolnego kodu. Polega ona na pewnej zależności: każdy program uruchomiony na komputerze używa specjalnego obszaru pamięci zwanego stosem (ang. stack). Obszar tej pamięci jest szczególny, ponieważ rośnie automatycznie wraz z zapotrzebowaniem na niego przez program. Jeśli jednak przyrost jest zbyt duży i zbliży się do innego obszaru pamięci (na przykład sterty – ang. heap) może dojść do sytuacji, w której program może pomylić stos z innym obszarem pamięci. Daje to możliwość wykorzystania owego zamieszania do nadpisania stosu przez inny obszary pamięci lub odwrotnie.

Jak zostało wspomniane nie jest to nowa technika. Pomysł zderzania stosu z innym obszarem pamięci został opisany po raz pierwszy w 2005 roku przez Gaël Delalleau. Po drugiej eksploatacji w 2010 r. przez Rafała Wojtczuka w systemie Linux został przedstawiony mechanizm obronny przed takimi exploitami: stack guard page. Niestety badania przeprowadzone przez Qualys Research Team pokazują, że ochrona ta może zostać łatwo ominięta przez atakujących. W celach demonstracyjnych, jako dowód koncepcji została opublikowana podatność CVE-2017-1000364. Badacze z Qualys opracowali również ataki, które używają Stack Clash do wykorzystania w oddzielnych lukach zabezpieczeń – na przykład: CVE-2017-1000365. W dodatku, jeśli połączymy lukę w programie sudo z 30 maja z w/w techniką to każdy lokalny użytkownik (nie tylko uprawniony “sudoers”) jest w stanie uzyskać pełne prawa administratora na każdym podatnym systemie.

Stworzono 14 PoCów oraz exploitów na podstawie Stack Clash, które działają na wszystkich wymienionych we wstępie systemach (na razie ich publikacja została wstrzymana w duchu odpowiedzialnego ujawniania, aby dać czas użytkownikom i administratorom na aktualizację systemów). Wszystkie podatności na razie są lokalnymi eskalacjami uprawnień, ale nie można wykluczyć, że specyficzne konfiguracje wybranych aplikacji mogą dopuszczać wariant zdalny. Wpływ luki, jaki może mieć na system Android na razie pozostaje nie określona. Dostawcy oraz developerzy dotkniętych systemów już wydali odpowiednie poprawki bezpieczeństwa (zwiększenie stack guard page z 4K do 1MB oraz rekompilacja programów z flagą gcc -fstack-check) tj.: SuSE, RedHat, Debian (1, 2, 3, 4), Ubuntu, OpenBSD, OpenSolaris (pakiety: sudo, exim, ld.so, rsh). Jeśli nie jesteśmy w stanie zaktualizować systemu lub wykonać jego restartu istnieje możliwość ustawienia limitu dla stosu do racjonalnie niskich wartości. Niestety to obejście niesie za sobą pewne ryzyko: najprawdopodobniej limity nie będą wystarczające niskie, aby można wykluczyć wszystkie ataki (na przykład wersja stack-clash dla sudo zaalokowała ledwo co 137MB sterty i prawie żadnej pamięci ze stosu) lub limity będą zbyt niskie i spowodują niewłaściwą pracę aplikacji.

Więcej informacji: An Ancient Kernel Hole is (Not) Closed