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 :)
2010-07-20:
Comments:
Ale to już nie ten sam fan...
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: