Aiv's dev blog

Dzisiaj w nocy aplikacja freshclam pobrała aktualizację definicji wirusowych do ClamAV. Od tej pory, ClamAV w każdym mailu napisanym w HTML’u, wykrywa “Exploit.PDF-9669“. Obecnie trwają pracę nad naprawą tego błędu.

Jako rozwiązanie doraźne, polecam (więcej…)

W sieci właśnie pojawił się publiczny lokalny exploit na kernela Linuxa. Wszystkie kernele z gałęzi 2.4 i 2.6 wydane od roku 2001 są podatne na nowy błąd:
- Linux 2.4, od 2.4.4 do 2.4.37.4 włączenie
- Linux 2.6, od 2.6.0 do 2.6.30.4 włączenie
Nie mam jeszcze informacji na temat kerneli z patchami typu grsecurity.
(więcej…)

Chciałbym zapoczątkować serię artykułów poświęconych tematyce Linuxa na urządzeniach mobilnych, a dokładniej na telefonach komórkowych nie koniecznie dostarczonych z Linuxem.

Głównym obiektem moich badań jest telefon Sony Ericsson Xperia X1, nazywany (głównie na zachodzie) też HTC Kovsky bądź HTC Venus. Telefon ten, dostarczany z Windows Mobile 6.1, wyposażony jest w procesor Qualcomm 7200A taktowany zegarem 528 Mhz. Procesor ten obsługuje zestaw instrukcji ARMv6.
(więcej…)

Samsung wypuścił na rynek telewizory LCD – Seria 7. Podczas aktualizacji firmware bardziej zainteresowani użytkownicy mogli zauważyć, że w pakiecie aktualizacyjnym mamy pliki/katalogi:

(więcej…)

W każdym banku internetowym mamy możliwość wydrukowania potwierdzenia zrealizowanego przelewu. W erze bankowości elektronicznej, potwierdzenia takie stają się coraz częściej rzetelnym dokumentem poświadczającym wpłatę należności za zakupy, usługi, rachunki itp.

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.
(więcej…)

Świat obiegła informacja o błędzie w funkcji vmsplice_to_user(). Błąd ten pozwala podnieść uprawnienia do root’a. Jako, że błąd jest strasznie trywialny (niesprawdzanie wskaźnika przyjmowanego przez funkcję) to natychmiast powstał działający exploit. (więcej…)

W dniu wczorajszym (3.I.2008) ukazała się nowa wersja PHP z serii 4 oznaczona numerem 4.4.8. Jako iż drzewo PHP4 nie jest już rozwijane, są to istotne poprawki wraz z zaleceniem natychmiastowej aktualizacji. Oto lista wprowadzonych modyfikacji: (więcej…)

Postanowiłem na własne potrzeby stworzyć pewien szablon konfiguracji PHP opartej o Apache. Podstawowym celem było bezpieczeństwo rozwiązania, a jak udało mi się to zrealizować – życie pokaże. W prezentowanych przykładach pominąłem większość parametrów konfiguracyjnych, a więc podczas tworzenia własnego środowiska na bazie niniejszego artykuły zalecam dostosowanie ich do własnych potrzeb.

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

(więcej…)

W PHP 5 wprowadzono pewne uproszczenie w tworzeniu plików php.ini np.: dla każdego virtualhosta oddzielnie. Zakładając, że mamy swój ulubiony plik php.ini, umieszczamy w nim na początku coś takiego:

Poniżej opisanych dyrektyw, możemy posługiwać się zmiennymi ${main_domain} i ${main_root_dir} np.: w taki sposób:

Niestety opcja ta nie jest dostępna w PHP 4 i w związku z zamknięciem rozwoju tej wersji, nie zostanie już dodana.

Chciałem sprawdzić czy można użyć kilku plików php.ini zakładając, że każdy kolejny plik nadpisuje ustawienia z plików poprzednich. Testowałem PHP w wersji 4.4.7 i 5.2.5 skompilowane jako CGI ze wsparciem dla FastCGI. Podczas konfiguracji użyłem między innymi parametrów:

Po krótkim debugowaniu aplikacji okazało się w jakiej kolejności PHP poszukuje plików ini:

Wyżej wymieniona kolejność jest taka sama dla PHP uruchamianego z poziomu FastCGI/CGI. W przypadku pominięcia parametru --enable-fastcgi zmianie ulega nazwa pliku php-cgi-fcgi.ini na php-cgi.ini.

W przypadku PHP uruchomionego jako moduł Apache sprawa ma się trochę inaczej:

(PHP było skompilowane z opcją --sysconfdir=/etc/php5/apache.)

Niestety testy które przeprowadziłem wykazały, że PHP po znalezieniu pierwszego pliku ini pomija dalsze lokalizacje. Planowałem na podstawie tego mechanizmu dać użytkownikom możliwość posiadania własnego pliku php.ini z gwarancją, iż niektóre parametry były by zawsze globalnie nadpisywane (np: open_basedir, czy disable_functions).