2010-07-20:

Stare advisory PHP EXIF

security:php:rant
Wczoraj wieczorem opublikowaliśmy (u j00ru na blogu) trochę starych advisory dotyczących PHP (nic poważnego, jakieś tam prawie nieistotne rzeczy, więc to bardziej wyniki badań niż literalnie "advisory"). W sumie nie tyle chodziło nam o znalezienie jakiś bugów w PHP (noo, trochę też, ale nvm ;p) co o przetestowanie nowej (dla nas) metody audytowania kodu.

Metoda (j00ru też ją opisał w poście, więc jeśli czytałeś(aś) post u niego, to pomiń tą część tekstu) jest trywialna, i w zasadzie wygrzebana z książki "Sztuka testowania oprogramowania" (w Polsce Helion ją wydał). Oto jak działa:

1. Zbieramy grupkę ludzi (2-3 osoby wystarczą, ale może być więcej) i drukujemy jakiś fragment kodu (ewentualnie wyświetlamy na ekranie, ale osobiście preferuje jednak wydruki ;>)
2. Wybieramy jedną osobę, która zaczyna na głos czytać kod, linia po linii, zaczynając od jakiegoś uzgodnionego punkty wejścia (funkcji, main(), etc)
3. Po każdej linii jest chwila przerwy na przedyskutowanie jej (czy jest bezpieczna, czy nie stanowi jakiegoś zagrożenia, etc; ofc cały czas ma się "w głowie" całokształt, a nie tylko tą linię). Jeśli linia jest bezpieczna, czyta się następną, etc. Jeśli nie, to albo się ją zaznacza, albo rzuca się do klawiatury i klepie PoC ;)
4. Oczywiście gdy osoba czytająca się zmęczy (można to rozpoznać po przejściu ów osoby na growl), można ją zmienić ;)

Moim zdaniem metoda ta ma dodatkowo pewne świetne walory edukacyjne, szczególnie dla osoby początkującej która w czymś takim bierze udział - można się masy rzeczy nauczyć ;)

W każdym bądź razie sprawdziliśmy w ten sposób moduł EXIF w PHP i znaleźliśmy trochę mniej istotnych (z punktu widzenia systemu) rzeczy:
- kilka (dokładniej trzy) memory disclosure'ów - czyli ujawnień fragmentów pamięci (bajt tu, dwa bajty tam, nie na tyle dużo by coś istotnego można z tego wywnioskować)
- kilka DoSów (znowu trzy) - niemniej jednak nic co udałoby się zamienić na code execution, ale i tak dość ciekawe (z punktu widzenia researchera ;p)

Napisaliśmy kilka PoCy i advisory i puściliśmy je do teamu PHP, dostaliśmy wstępną odpowiedź, a potem... (a teraz się wyjaśni czemu post jest otagowany rant ;p)
Ehm, no właśnie, i tu jest problem. Nie mam zielonego pojęcia czy coś się potem z tymi bugami działo, bo team PHP przestał dawać znaki życia, tj. odpisywać na e-maile, czy choćby dać znać że już poprawili bugi (dostaliśmy wstępną odpowiedź, więc szliśmy torem typowego vendor-coordinated disclosure (mimo że to naprawdę nic specjalnie istotnego nie jest)).

Jakiś czas temu sprawdziliśmy, i się okazało że w najnowszej wersji PHP bugi zostały poprawione, natomiast nie udało nam się w changelog żadnych wzmianek znaleźć (zrozumiałe, nic istotnego jak pisałem), no i nigdy nie otrzymaliśmy żadnej informacji od teamu PHP czy w końcu to poprawili.

Jak cały czas zaznaczam, zdaję sobie sprawę, że nie były to specjalnie istotne rzeczy. Niemniej jednak imo było by dość fajnie gdybyśmy dostali choćby mejla z "OK Fixed" (raptem 8 znaków).
Cóż, wygląda na to że team PHP dołączył do Mozilli na mojej osobistej liście 'vendorów którzy przestają odpisywać na e-maile' ;p

OK, koniec narzekania :)

Advisory:
PHP 5.2.10 / 5.3.0 EXIF Denial of Service 1
PHP 5.2.10 / 5.3.0 EXIF Denial of Service 2
PHP 5.2.10 / 5.3.0 EXIF Denial of Service 3
PHP 5.2.10 / 5.3.0 Multiple Memory Disclosure

To tyle :)

Comments:

2010-07-20 20:27:52 = przemoc
{
Czasem ponarzekać trzeba, tym bardziej jeżeli jest to zasadne narzekanie. Wydaje mi się, że to jest szerszy problem, nie tylko dotyczący bugów. Zdarza się, że czasem ktoś np. nadsyła jakiś patch poprawiający coś, usprawniający lub dodający jakąś funkcję w oprogramowaniu typu open source. Później może nawet i dostać "Thank You" czy coś w ten deseń, ale nigdzie, w całym projekcie czy nawet repozytorium, choćby w commicie, nie ma potem wzmianki, kto jest autorem wprowadzonych zmian. Co więcej, dla niepoznaki bywają one przemieszane z innymi (w sensie w danym commicie). Tu przecież nie chodzi o jakieś fanfary na cześć autora łaty, ale zwykłe "Submitted by", "Courtesy of", "Thanks to", whatever, które mogą trafić właśnie do samego commita bez "zaśmiecania" plików projektu nickiem/inicjałami/nazwiskiem autora.
}
2010-07-20 21:17:51 = faramir
{
W NetBeans, jeśli jakiś zgłoszony bug w nowej wersji ma status FIXED/CLOSED to jest przysyłany mail (z automatu pewnie), w którym jest podziękowanie za rozwój systemu i rozwiązanie problemów związanych ze zgłoszonym błędem. Dobra metoda. W commitach bym się tego nie spodziewał, ale jeśli wszystko ma jakieś opisy na bugtracku lub innym systemie z ticketami, to jeśli w commicie jest zaznaczone, że rozwiązał problem z bugiem1234, to wiadomo, gdzie szukać informacji o autorze.
}
2010-07-20 21:22:55 = oshogbo
{
@faramir
Ale to już nie ten sam fan...
}
2010-07-20 21:32:23 = przemoc
{
@faramir
Jasne, chodzi przecież o możliwość łatwego dotarcia do autora. Numery identyfikacyjne Bug/PR-ów są jak najbardziej w porządku. Odnosiłem się do sytuacji gdy autor przesyła łatę drogą mailową (niech to będzie publiczna lista mailingowa). Po prostu taki ML zazwyczaj (bardzo) luźno związany jest z kodem projektu (w sensie kod "nie powołuje się" na ML, itd.), a brak jakiegokolwiek odnośnika w commicie powoduje, że nikt nawet nie spodziewa się, że autorem podsyłanego kodu jest ktoś inny od commitera. W SCM-ach stricte rozróżniających autora od commitującego, jak git, można oczywiście wyraźnie zaznaczyć autorstwo bez wzmianki w samej wiadomości. Wówczas wspomniane "Submitted by", "Courtesy of", "Thanks to", whatever można sobie darować, jako redundantne.

Jest to problem mentalny na styku z narzędziem, bo tego typu "nadużycia" chyba właśnie częściej występują w CVS-ach i SVN-ach.
}

Add a comment:

Nick:
URL (optional):
Math captcha: 5 ∗ 4 + 10 =