automatyczna aktualizacja

Automatyczna aktualizacja to mechanizm, w którym oprogramowanie samo pobiera i instaluje nową wersję, bez udziału administratora. W WordPressie automatyczne aktualizacje w tle wprowadzono w wersji 3.7, aby poprawić bezpieczeństwo i uprościć proces aktualizacji ^[1]. Domyślnie obejmują one mniejsze wydania rdzenia i pliki tłumaczeń ^[1], a od wersji 5.5 administrator może je włączyć także dla wybranych wtyczek i motywów ^[3]. CERT Polska zwraca uwagę, że automatyzacja pobierania i dystrybucji aktualizacji bezpieczeństwa przyspiesza ich dostarczanie ^[7].

Jak działa

Mechanizm opiera się na zadaniach harmonogramu WordPress Cron. Dokumentacja podaje, że domyślnie WordPress uruchamia automatyczne aktualizacje dwa razy dziennie ^[3]. Jeśli harmonogram nie działa poprawnie, aktualizacje się nie wykonają; błędy tego rodzaju pokazuje ekran Narzędzia → Stan witryny ^[3].

Po każdej próbie aktualizacji wtyczek i motywów WordPress domyślnie wysyła e-mail do właściciela strony: gdy aktualizacja się udała, gdy się nie udała i gdy część elementów zaktualizowała się, a część nie ^[3]. Przebieg pojedynczego cyklu pokazuje schemat poniżej.

RYS. 1Cykl automatycznej aktualizacji w WordPressie

Automatyczne aktualizacje nie ruszą, gdy WordPress wykryje kopię roboczą systemu kontroli wersji ^[1]. Aktualizacja wymaga też, by serwer mógł zapisać nowe pliki, więc przeszkodą bywają zbyt restrykcyjne uprawnienia plików.

Rodzaje

WordPress rozróżnia kilka rodzajów aktualizacji i każdy ma inne ustawienie domyślne.

Aktualizacje rdzenia opisuje osobno hasło aktualizacja rdzenia WordPressa. Automatyczna aktualizacja jest jednym ze sposobów dostarczenia łatki (patch), czyli poprawki usuwającej podatność.

W WordPressie

Panel. Na ekranie Wtyczki jest kolumna z odnośnikiem, który włącza albo wyłącza automatyczną aktualizację każdej wtyczki osobno; można to też zrobić akcją zbiorczą ^[3]. Motywy włącza się pojedynczo w oknie szczegółów motywu na ekranie Wygląd ^[3]. Jeśli tych przełączników brakuje, dokumentacja wskazuje, że funkcję mógł wyłączyć hosting albo wtyczka ^[3].

Stałe w wp-config.php. Stała AUTOMATIC_UPDATER_DISABLED wyłącza wszystkie automatyczne aktualizacje ^[1]. Stała WP_AUTO_UPDATE_CORE przyjmuje wartość true (aktualizacje rozwojowe, mniejsze i główne), false (żadne) albo 'minor' (tylko mniejsze) ^[1]. Strona o pliku wp-config.php opisuje 'minor' jako zachowanie domyślne ^[2], a przewodnik po aktualizacjach dodaje, że instalacje utworzone od wersji 5.6 dostają też główne wydania, o ile nie wykryto kontroli wersji ^[1].

// wp-config.php — tylko mniejsze wydania rdzenia
define( 'WP_AUTO_UPDATE_CORE', 'minor' );

Filtry. Filtry auto_update_plugin i auto_update_theme włączają lub wyłączają aktualizacje hurtowo; wartość zwrócona przez filtr nadpisuje ustawienia wybrane w panelu ^[4]. Filtry plugins_auto_update_enabled i themes_auto_update_enabled ukrywają tylko przełączniki w interfejsie, same aktualizacje zostawiają bez zmian ^[4]. Dokumentacja zaleca umieszczanie filtrów aktualizacji we wtyczkach mu-plugins, a nie w wp-config.php ^[1].

Znaczenie

CERT Polska opisuje, że publiczna informacja o nowej krytycznej podatności uruchamia prace nad sposobami jej wykorzystania ^[7]. Organizacja powinna zakładać, że systemy z podatnościami na pewno staną się celem ataku ^[7]. Czas między publikacją poprawki a jej instalacją to okno, w którym działa exploit na znaną lukę, czyli podatność typu n-day.

W WordPressie problem dotyczy głównie dodatków: podatność we wtyczce albo w motywie zostaje na stronie, dopóki ktoś nie zainstaluje poprawionej wersji. Automatyczna aktualizacja skraca to okno, ale nie pomoże przy porzuconej wtyczce, dla której nowa wersja nie powstaje. Szerzej to ryzyko opisuje hasło Vulnerable and Outdated Components.

Ryzykiem po drugiej stronie jest awaria po aktualizacji. Propozycja „Rollback Auto-Update” z kwietnia 2024 roku, planowana na wersję 6.6, zakłada zapytanie zwrotne (loopback) do strony głównej po aktualizacji wtyczki ^[6]. Po wykryciu błędu krytycznego PHP przywracana jest poprzednia wersja, a na adres administratora trafia powiadomienie ^[6].

Dobre praktyki

• Przed włączeniem automatycznych aktualizacji dokumentacja WordPressa zaleca upewnić się, że da się przywrócić poprzednią wersję strony, na przykład z regularnej kopii zapasowej (backup) ^[3].
• CERT Polska proponuje, by pierwszą partię aktualizowanych serwerów ograniczyć do grupy kontrolnej i kontynuować po sprawdzeniu poprawności ^[7]. Dla jednej strony odpowiednikiem jest środowisko testowe (staging).
• Automatyczna aktualizacja to jeden element szerszego procesu, jakim jest zarządzanie poprawkami (patch management). Gdy poprawki jeszcze nie ma, lukę może przejściowo osłonić wirtualne patchowanie (virtual patching) w WAF.
• Warto czytać e-maile o wyniku aktualizacji i sprawdzać ekran Stan witryny, bo niedziałający Cron po cichu wstrzymuje cały mechanizm ^[3].

Historia i przykłady

WordPress 4.7.2 (2017). 20 stycznia 2017 roku badacz firmy Sucuri zgłosił nieuwierzytelnioną eskalację uprawnień w punkcie końcowym REST API, dotyczącą wersji 4.7 i 4.7.1 ^[5]. Wersja 4.7.2 ukazała się 26 stycznia, a opis luki opublikowano 1 lutego, celowo z tygodniowym opóźnieniem ^[5]. Zespół bezpieczeństwa napisał, że w ciągu kilku godzin miliony użytkowników wersji 4.7.x zostały zabezpieczone bez żadnego działania z ich strony, właśnie dzięki automatycznym aktualizacjom ^[5].

UpdraftPlus (2022). Wtyczka do kopii zapasowych UpdraftPlus, mająca ponad 3 miliony instalacji, zawierała błąd, przez który nisko uprzywilejowany użytkownik mógł uzyskać dostęp do kopii strony ^[8]. Przyczyną była niewystarczająca weryfikacja uprawnień; poprawka trafiła do wersji 1.22.4 i 2.22.4 ^[8]. WordPress podjął nietypowy krok i wymusił aktualizację; według statystyk zainstalowało ją blisko 2 miliony serwisów ^[8].