Problem dotyczy wersji Apache działających w trybie reverse proxy - ten typ konfiguracji wykorzystywany jest do równoważenie obciążenia, cache'wania danych oraz innych operacji zakładających rozpraszanie zasobów po wielu serwerach.

Aby Apache HTTPD mógł działać jako reverse proxy, administrator serwera musi wykorzystać odpowiednie moduły - np. mod_proxy oraz mod_rewrite. Specjaliści z firmy Qualys wykryli, że jeśli pewne reguły nie zostaną właściwie skonfigurowane, możliwe jest wysłanie do serwera zapytań, które pozwolą nieautoryzowany dostęp do wewnętrznej sieci.

Zobacz również:

• Luka w zabezpieczeniach WordPress

Co ciekawe, problem nie jest nowy - bardzo zbliżony błąd został usunięty z Apache w październiku. Okazało się jednak, że przygotowana wtedy przez developerów serwera poprawka nie jest doskonała i można ją obejść, odpowiednio wykorzystując lukę w module odpowiedzialnym za obsługę URI (Uniform Resource Identifier).

Jedną ze stosunkowo często stosowanych reguł jest " ^(.*) http: //internal_host$1", która przekierowuje żądanie do wewnętrznego hosta. Jednakże jeśli serwer otrzyma żądanie np. "host::port" (z dwoma dwukropkami), część "host:" zostaje oddzielona a reszta dodana do przekierowania http: //internal_host.

Problem polega na tym, że część ":port" przenosi żądanie do http: //internal_host:port co może narazić wewnętrzne zasoby. Zdaniem eksperta administratorzy powinni zmodyfikować regułę dodając znak "/" przed $1 (czyli omawiana reguła powinna wyglądać "^(.*) http: //internal_host/$1"/).

Przedstawiciele projektu Apache wiedzą już o problemie i aktualnie ustalają, jaki sposób usunięcia luki będzie optymalny. Rozważane jest m.in. poprawienie poprzedniej aktualizacji - aczkolwiek nie jest pewne, czy to w 100% zablokuje możliwość obchodzenia zabezpieczeń. Alternatywną metodą ma być przygotowanie odrębnej aktualizacji, rozwiązującej ten konkretny problem z URI.