Zend Framework i jego następca – Laminas Project to popularne narzędzia deweloperskie. Okazuje się, że mogą być wykorzystywane do zdalnego wykonywania kodu na stronach internetowych opartych na PHP, jeśli uruchamiają one aplikacje, które są podatne na atak.
Osoby odpowiedzialne za utrzymanie Zend Framework, podkreślają, że warunki, w których aplikacja internetowa może być nadużywana, najpierw wymagają od autora aplikacji napisania jej w „niebezpieczny” sposób. Z tego powodu obecni opiekunowie Zend Framework kwestionują, czy klasyfikacja podatności jest poprawna.
„Kwestionujemy tę lukę i uważamy naszą łatkę za poprawkę zwiększającą bezpieczeństwo, a nie poprawkę luki w zabezpieczeniach” – powiedział Matthew Weier O’Phinney, właściciel produktu Zend i główny inżynier.
Które wersje są podatne?
Problem dotyczy Zend Framework w wersji 3.0.0 i Laminas Project laminas-http przed 2.14.2. Internet szacuje, że z tych wersji frameworka korzysta nawet kilka milionów stron i prawdopodobnie są one dotknięte podatnością.
Błąd został publicznie ujawniony kilka dni temu przez badacza cyberbezpieczeństwa Ling’a Yizhou, który opublikował również dwa scenariusze ataków typu “proof-of-concept”. Błąd, śledzony jako CVE-2021-3007 nie ma oceny krytyczności na liście MITER, jednak członkowie społeczności cyberbezpieczeństwa oceniają to jako „wysokie ryzyko” i dają mu przynajmniej 7,5 / 10.
Koniec wsparcia dla Zend Framework nastąpił 31 grudnia 2019 roku, po czym został on włączony do Projektu Laminas. Według opiekunów Zend Framework i Laminas Project są równoważne i ich funkcjonalności nie odbiegają od siebie.
Na czym polega podatność?
Według Yizhou, wersja Zend Framework 3.0.0 ma lukę w deserializacji, która może prowadzić do zdalnego wykonania kodu. Podatność dotyczy metody _destruct klasy Zend\Http\Response\Stream w Stream.php.”
Scenariusze ataków typu Proof-of-Concept (PoC) na Zend Framework i Laminas Project zostały opublikowane na stronie GitHub prowadzonej przez badacza bezpieczeństwa Yizhou.
Deserializacja i serializacja to terminy techniczne opisujące proces przekształcania jakiegoś obiektu (kodu) w format danych (serializacja), który można później odwrócić (deserializacja). Koderzy często serializują obiekty w celu zapisania ich w pamięci masowej lub wysłania w ramach komunikacji.
Luka w zabezpieczeniach związana z deserializacją występuje, gdy dane kontrolowane przez użytkownika są deserializowane przez witrynę internetową. Innymi słowy, gdy witryna umożliwia użytkownikowi wprowadzenie niezaufanych danych lub wykonanie wstrzyknięcia innego obiektu do aplikacji internetowej. Wstrzyknięte dane mogą nadużywać logiki aplikacji i wywołać atak typu „odmowa usługi” (DoS) lub pozwolić osobie atakującej na wykonanie dowolnego kodu podczas deserializacji danych.
Słowo na koniec
Projekt Laminas firmy Linux Foundation kwestionuje klasyfikację CVE. W oświadczeniu opublikowanym na jego stronie GitHub stwierdzono:
„Uważamy, że nie jest to luka specyficzna dla frameworka, ale bardziej ogólnie dla języka. Funkcje serialize() i unserialize() mają długą historię luk w zabezpieczeniach i programiści nie powinni NIGDY używać ich na niezaufanych danych wejściowych. Jeśli jest to niemożliwe, powinni przynajmniej przekazać drugi argument `$ options` i podać listę dozwolonych klas lub użyć argumentu, aby uniemożliwić wszelką nieserializację obiektów”.
Twórcy framework’a twierdzą więc, że podatność jest ściśle związana z językiem PHP i nie ma związku z ich narzędziem. Ponadto stwierdzają, że klasyfikacja jest bardziej ogólnie rozumiana jako „wstrzyknięcie obiektu PHP” i nie jest specyficzna dla żadnego określonego framework’a.
Niezależnie od tego, programiści z Linux Foundation udostępnili poprawkę, aby jeszcze bardziej chronić użytkowników przed takimi scenariuszami. Łatka zapewnia sprawdzenie typu właściwości $streamName przed wykonaniem operacji.