Jako rozwiązanie doraźne, polecam odnaleźć plik daily.hdb i wyedytować go.
Pod koniec pliku znajdujemy linijkę:

i kasujemy ją.

Restart clamd na koniec, celem załadowania poprawionych definicji.

Na koniec chciałbym dodać najserdeczniejsze pozdrowienia dla osoby która dodała/zaakceptowała taką regułę do definicji wirusowych.

Niestety opublikowany exploit działa bardzo ładnie:

Do pobrania exploit wunderbar_emporium

Aktualizacja 1:
Po przeprowadzeniu testów, niestety okaząło się, że na kernele z patchem grsec exploit też działa. Wymaga co prawda zmian w kodzie źródłowym, ale osoba znająca trochę C jest w stanie wprowadzić zmiany bez większego problemu.

Aktualizacja 2:
Mały patch Linusa Torvaldsa, dostępny w repozytorium kernela rozwiązuje problem w chwili obecnej. Nie analizował zasady działania kernel_sendpage(). Sprawdziłem zachowanie exploita z nowym kernelem.

Potwierdzenia takie są zazwyczaj łatwo modyfikowalne dla użytkownika mającego podstawową wiedzę na temat HTML’a, bądź dowolnego programu graficznego.

A co w wypadku, kiedy to sam bank daje nam narzędzie do drukowania fałszywych potwierdzeń realizacji przelewu? Taka sytuacja ma miejsce w BRE Banku, a dokładniej jego detalicznym brandzie – mBank.

Poniżej przedstawiam krótki opis zasady działania mBanku:
W przypadku zlecenia realizacji przelewu, trafia on do kolejki, która zostanie wysłana najbliższą sesją wychodzącą. W tym czasie użytkownik zamiast guzika “Wydruk potwierdzenia” widzi komunikat “** Przelew nie został jeszcze zrealizowany **”. Podobny komunikat widoczny jest w przypadku odwołanego zlecenia przelewu: “** Wydruk potwierdzenia jest niedostępny, gdyż przelew został odrzucony. **”.

Uwaga: Fałszowanie dokumentów bankowych jest przestępstwem

Korzystając z oprogramowania do zmiany zawartość pamięci podręcznej przeglądarki, można podmienić ww. tekst na kod odpowiadający wywołaniu drukowania potwierdzenia przelewu:

Po kliknięciu na dodany w ten sposób przycisk, uzyskujemy dokument potwierdzający realizację przelewu. Dokument taki zawiera wszystkie dane, jak w przypadku oryginalnego potwierdzenia w tym unikalny numer referencyjny.

Ww. podatność można wykorzystać w obu przypadkach: potwierdzenia niezrealizowanego jeszcze przelewu jak i potwierdzenia odwołanego już zlecenia.

BRE Bank jest operatorem marki Multibank i być może ww. sytuacja ma zastosowanie też w systemie Multibanku.

mBank został poinformowany o wyżej opisanej sytuacji 8 października 2008r.

Zalecany jest upgrade do najnowszej wersji (jeszcze z drzewa SVN). Innym wyjściem jest zastosowania programu (modyfikacji dostępnego exploita), który znajduje adres funkcji sys_vmsplice przy użyciu /proc/kallsyms i zamienia pierwszy bajt funkcji na instrukcje RET.

Exploit na dziurę vmsplice_to_user() w kernelach 2.6.17 – 2.6.24.1
Modyfikacja explita zamieniająca pierwszy bajt na instrukcję RET

• Improved fix for MOPB-02-2007.
• Fixed an integer overflow inside chunk_split(). Identified by Gerhard Wagner.
• Fixed integer overlow in str[c]spn().
• Fixed regression in glob when open_basedir is on introduced by #41655 fix.
• Fixed money_format() not to accept multiple %i or %n tokens.
• Addded “max_input_nesting_level” php.ini option to limit nesting level of input variables. Fix for MOPB-03-2007.
• Fixed INFILE LOCAL option handling with MySQL – now not allowed when open_basedir or safe_mode is active.
• Fixed session.save_path and error_log values to be checked against open_basedir and safe_mode (CVE-2007-3378).
• Fixed bug #43010 (Fixed regression in imagearc with two equivelent angles).
• Fixed bug #41765 (Recode crashes/does not work on amd64).
• Fixed bug #41630 (segfault when an invalid color index is present in the image data).
• Fixed bug #41628 (PHP settings leak between Virtual Hosts in Apache 1.3).
• Fixed bug #38798 (OpenSSL init corrected in php5 but not in php4).

Większość z ww. modyfikacji ma istotny wpływ na bezpieczeństwo środowiska w którym się znajduje.

Na potrzeby niniejszej konfiguracji użyłem:

• Linux Slackware w wersji 12. Starałem się nie używać ustawień i pakietów pochodzących z dystrybucji, żeby rozwiązanie było jak najbardziej uniwersalne
• Apache w wersji 2.2.6
• FastCGI w wersji 2.4.6
• PHP w wersji 4.4.7 i 5.2.5

Przyjąłem również kilka założeń:

• Skrypty PHP powinny być uruchamiane w zamkniętym środowisku (np: chroot() albo open_basedir())
• Skrypty PHP powinny być uruchamiane z uprawnieniami właściciela pliku/virtualhosta
• Każdy użytkownik powinien mieć indywidualny folder tmp i folder przechowywania plików sesji
• Każdy użytkownik sam może wybrać wersji PHP
• Dla każdego virtualhosta powinien istnieć oddzielny plik php.ini
• Tworzone rozwiązanie powinno być jak najbardziej uniwersalne. Jednocześnie powinno oferować administratorowi wygodę zarządzania

Instalacja Apache:

Apache wraz z modułem suexec potrafi uruchamiać skrypty CGI z uprawnieniami użytkownika. Model bezpieczeństwa suexec wymaga deklarowania zmiennych środowiskowych, które mają być przekazywane do CGI. Większość zmiennych środowiskowych np.: REQUEST_URL, DOCUMENT_ROOT itp. są wpisane na stałe do pliku support/suexec.c, jednak brakuje tam zmiennych dla PHP, które pomagają mu współpracować z modułem FastCGI. Musimy je ręcznie dopisać, a więc otwieramy plik support/suexec.c w ulubionym edytorze tekstowym i znajdujemy kod:

Dopisujemy przed linijką zawierającą AUTH_TYPE:

Plik wynikowy powinien wyglądać następująco:

Dzięki wykonanej modyfikacji suexec będzie przekazywał zmienne środowiskowe, które ustawi FastCGI, do wrappera PHP (w dalszej części artykuły opisze obie zmienne i dlaczego trzeba było wprowadzić tą poprawkę).

Teraz możemy przystąpić do rzeczywistej konfiguracji Apache. Uruchamiamy komendę:

Opis parametrów:

• –enable-so: włączenie mechanizmu DSO
• –with-suexec-caller: użytkownik z którego będzie wywoływany suexec. Należy tutaj wpisać nazwę użytkownika na którym działa Apache
• –with-suexec-docroot: ścieżka w której znajdują się wszystkie skrypty PHP uruchamiane przez suexec
• –with-suexec-logfile: plik do którego suexec będzie logował. Należy pamiętać o utworzeniu takiego pliku i nadaniu mu uprawnień do zapisu dla użytkownika na którym działa Apache. Należy mieć też na uwadze konieczność rotowania tego pliku – Apache się tym nie zajmuje
• –enable-suexec: włączenie mechanizmu suexec
• –enable-cgi:włącza obsługę CGI – niezbędne do konfiguracji PHP jako CGI
• –with-suexec-bin: ścieżka do pliku suexec w naszym systemie. Plik ten może znajdować się w dowolnym miejscu

Jeżeli nie dodałeś żadnego layoutu ustawień (–enable-layout=LAYOUT) podczas konfigurowania Apache, pliki zostaną umieszczone w katalogu /usr/local/apache2. Jeżeli zmieniłeś layout, pamiętaj o zmianie ścieżki do pliku suexec (–with-suexec-bin).

Instalacja FastCGI:

Konfiguracja FastCGI sprowadza się do wykonywania instrukcji instalacyjnych z pliku INSTALL.AP2. Należy pamiętać o zmianie ścieżki top_dir w przypadku innej konfiguracji Apache. We wskazanym katalogu powinien się znaleźć plik build/special.mk:

Instalacja PHP:

Instalacja obu wersji PHP przebiega podobnie dlatego opiszę tylko jedną wersję w tym miejscu. W przypadku PHP 4 zalecał bym tylko zmianę prefixu na /usr/local/php4. Dalsza część artykułu zawiera konfiguracje dla systemu z obiema wersjami PHP.

Celowo nie dodawałem tutaj parametru –sysconfdir, który wskazuje na miejsce szukania domyślnego pliku php.ini. Będę używał parametru -c do wskazania pliku php.ini. Dowiedz się więcej o kolejności ładowania plików php.ini z mojego artykułu.

Opis parametrów:

• –prefix: prefix instalacji ustawiłem na /usr/local/php5 gdyż równolegle będziemy instalować php4 i dobrze by było gdyby dwie wersji nie wchodziły sobie w drogę
• –enable-force-cgi-redirect: parametr ten zabezpiecza przed wywołaniem skryptu PHP poprzez link bezpośredni do skryptu FastCGI w folderze fcgi. Skrypt PHP zostanie wykonany tylko i wyłącznie jeżeli odwołanie do parsera zostało wykonane przez Apache
• –enable-fastcgi: włączenie obsługi FastCGI w parserze PHP

Zanim wykonasz poniższe komendy utwórz katalog /usr/local/php5.

W tym momencie zakończyliśmy instalacje i podstawową konfigurację niezbędnego programowania. Przystąpmy zatem do dalszej konfiguracji.

Konfiguracja Apache:

Plik konfiguracyjny Apache (httpd.conf) powinien zawierać między innymi takie ustawienia:

Opis parametrów:

• FastCgiWrapper: w tym miejscu deklarujemy wrapper dla FastCGI. Zamiast suexec możemy użyć np. cgiwrap albo sbox. Jeżeli chcemy użyć tego samego wrapper co Apache możemy ustawić tą opcję na “On”
• FastCgiConfig: deklarujemy w jaki sposób ma się zachowywać FastCGI
• -initial-env PHP_FCGI_CHILDREN=1: Ustawia zmienną środowiskową PHP_FCGI_CHILDREN która poprzez wrapper (np.: suexec) przekazujemy do PHP. Jeżeli nie zmodyfikowali byśmy źródeł suexec , zmienna ta została by wycięta. PHP_FCGI_CHILDREN określa ile procesów potomnych ma obsługiwać żądania PHP dla jednego virtualhosta
• -initial-env PHP_FCGI_MAX_REQUEST=5000: Zmienna ta określa maksymalną ilość żądań po których dany proces zostanie zakończony i uruchomiony w razie potrzeby od nowa
• -singleThreshold 90: Parametr przyjmuje wartości liczbowe od 0 do 100. FastCGI na tej podstawie określa czy dany proces ma być utrzymywany (wartość bliższa 1) czy zabity (bliżej 100) jeżeli nie jest już wykorzystywany. Jeżeli zależy Ci się na oszczędności pamięci ustaw ten parametr bliżej 100. Ustawienie na 0 zapobiegnie wyłączaniu ostatniego procesu potomnego
• -killInterval 300: Wartość parametru w sekundach, określa po jakim czasie bezczynności proces ma zostać zabity
• -autoUpdate: Powoduje sprawdzanie daty skryptów FastCGI. Jeżeli któryś z nich zostanie zaktualizowany, FastCGI zabije proces i uruchomi go od nowa
• -idle-timeout 240: Czas w sekundach który ma skrypt PHP na uruchomienie i rozpoczęcie zwracania wyników użytkownikowi
• -pass-header HTTP_AUTHORIZATION: Przekazania nagłówków uwierzytelniania HTTP do CGI. Standardowo nagłówki te nie są przekazywane

Przyjąłem, że każdy virtualhost posiada swój katalog w /var/www. Struktura prezentuje się następująco:
/var/www/host1.example.com
/var/www/host1.example.com/htdocs – główny folder dostępny przez http
/var/www/host1.example.com/htdocs/fcgi – folder ze skryptami FastCGI
/var/www/host1.example.com/tmp – folder przeznaczony na pliki sesji i pliki tymczasowe

Konfiguracja virtualhosta:

Opis parametrów:

• SuexecUserGroup v1 v1: określa systemowego użytkownika i grupę na którą suexec ma przenieść uprawnienia
• <Location /fcgi/php5>…</Location>: Zarejestrowanie pliku /fcgi/php5 jako skryptu FastCGI
• <Location /fcgi/php4>…</Location>: Jw. tylko, że dla pliku /fcgi/php4
• <Directory>…</Directory>: Ustawienia katalogu fcgi. Należy tutaj szczególną uwagę zwrócić na “Options None”. Zabezpiecza to przed możliwością uruchamiania programów niż zadeklarowane w <Location …>. Dodatkowo opcja “AllowOverride None” zabezpiecza przed możliwością zmiany tych ustawień z poziomu pliku .htaccess
• AddHandler php5-fastcgi .php: Ustawia domyślny interpretator dla plików .php na PHP 5. Gdyby użytkownik chciał zmienić wersje PHP na inna wystarczy, że sam we własnym zakresie stworzy plik .htaccess i wpisze do niego AddHandler php4-fastcgi .php
• Action php5-fastcgi /fcgi/php5: Deklaracja skryptu FastCGI dla PHP 5
• Action php4-fastcgi /fcgi/php4: Deklaracja skryptu FastCGI na PHP 5

Trzy opisane na końcu parametry można umieścić poza sekcją <VirtualHost>…</VirtualHost> czyniąc z nich ustawienia globalne dla serwera.

Teraz utworzymy skrypty FastCGI zadeklarowane w konfiguracji Apache. Skrypty te musimy utworzyć dla każdego virtualhosta w katalogu htdocs/fcgi.
Dla PHP 5 tworzymy plik htdocs/fcgi/php5:

Dla PHP tworzymy plik htdocs/fcgi/php4:

Niektórzy zadadzą sobie teraz pytanie “Po co dodawać każdemu katalog fcgi razem ze skryptami skoro mogę zrobić jeden katalog i podlinkować go każdemu?”.

Odpowiedź leży w źródłach suexec, które edytowaliśmy na początku. Model bezpieczeństwa suexec jest bardzo restrykcyjny i dokładnie porównuje uprawnienia uruchamianych programów razem z folderami virtualhosta. Jeżeli chodź jeden z testów nie będzie zgodny, skrypt nie zostanie uruchomiony. Rozwiązaniem jest modyfikacja źródeł suexec albo rozwiązanie problemu poprzez kopiowanie skryptów FastCGI do każdego virtualhosta. Pamiętaj o zmianie właściciela plików php4 i php5.

W tym miejscu powinienem powrócić jeszcze do modyfikacji suexec, którą wykonaliśmy na początku. Nic nie stało na przeszkodzie żebyśmy dopisali do utworzonych przed chwilą skryptów export zmiennych globalnych np.:

Modyfikację tą wprowadzaliśmy jednak, żeby istniała możliwość ustawienia tych parametrów globalnie. Jeżeli jeden z virtualhostow wymaga innej konfiguracji to możemy zmodyfikować te wartości właśnie poprzez export jak na ww. przykładzie.

Pliki konfiguracyjne php.ini:

Żeby cała ta konfiguracja zdała egzamin musimy w przygotować indywidualne pliki php.ini dla każdego virtualhosta. W przypadku PHP 5 sprawa jest odrobinę ułatwiona. Temat ten opisałem w artykule “Uproszczenie w konfiguracji PHP 5 per virtualhost“.W pliku konfiguracyjnym obu wersji PHP powinny się znaleźć:

Finalizacja:

Na koniec pozostaje nam kilka problemów do rozwiązania, a mianowicie:

• użytkownik może zmodyfikować zawartość skryptów znajdujących się w htdocs/fcgi, a co za tym idzie, dajemy mu dostęp do powłoki systemu, czego z pewnością większość z Was wolała by uniknąć
• użytkownik może zmienić/skasować plik php.ini. Ma wtedy dostęp do modyfikacji spersonalizowanych wartości open_basedir, error_log, session.save_path, disable_functions itp.

Żeby rozwiązać te problemy, należało by zabrać użytkownikowi możliwość edycji plików w katalogu htdocs/fcgi. Gdy zabierzemy mu uprawnienia poprzez zmianę właściciela, suexec bardzo szybko przypomni nam o tym fakcie. Rozwiązanie jakie znalazłem niestety nie jest eleganckie, ale za to jest skuteczne.

Użytkownicy systemu plików ext2/3 mogą nadać atrybut +i dla katalogu htdocs/fcgi poprzez chattr +i fcgi. Uniemożliwi to wprowadzanie zmian na folderze fcgi (razem z jego zawartością) dla wszystkich użytkowników systemu. Tak założone atrybut +i zdejmuje tylko i wyłącznie root.

Change log artykułu:

Będę się starał uaktualniać ten artykuł, a więc w tym miejscu opisze przyszłe zmiany.
25/02/2008 19:38 – Usunięcie niepoprawnych spacji z konfiguracji VirtualHost.
04/02/2008 17:41 – Zmieniłem nazwę “apache2.conf” na “httpd.conf” celem poprawienia zgodności z domyślną konfiguracją Apache.
30/01/2008 20:28 – Zmiana <IfModule> na </IfModule> w konfiguracji Apache.
25/01/2008 12:26 – Poprawka związana z błędną nazwa foldera w przykładowej konfiguracji Apache. Zamienione “fcgi-bin” na “fcgi”.
30/12/2007 16:45 – Publikacja pierwszej wersji