12.12.2017, 21:52
Moge się wypowiedzieć jako dev PHP i powiem tak - to odnośnie tego języka to brednie. Kilka informacji:
1. shell_exec może być wyłączone przy pomocy ustawienia disable_functions, choć często jest domyślnie włączone (np. PHP z repo debianowych / ubuntu (wraz z ppa) czy na centosie). Dlaczego? Bo nie ma powodu go wyłączać.
2. Polecenie to służy do odpalania poleceń shellowych (systemowych), a więc daje ogromne możliwości - choć wpływ na to ma masę kwestii (patrz niżej).
3. W PHP mamy do dyspozycji coś takiego jak open_basedir, które limituje nam "widoczność" drzewa katalogów dla PHP i operacji na nich. W efekcie ustawieniem tym - mocno to upraszczając - możemy "zamknąć" interpretatory PHP w np. katalogu witryny aby nie miały nawet możliwości odczytywania tego, co jest wyżej.
4. Nawet jeśli nie ustawimy powyższe, w grę wchodzą ustawienia dostępu do plików, nadal respektowane.
5. Jeśli zechcemy, możemy odpalać PHP (i cały serwer webowy) ze zmienionym katalogiem głównym przy pomocy chroota, co powoduje, że także wszystko w shell_exec jest ograniczone.
6. Na koniec najważniejsze - w dokumencie przedstawiono kod który opiera się na tym, że możemy sobie zdefiniować jakąś stałą, a następnie próbujemy jej użyć gdzieś, gdzie nie mamy jej zdefiniowanej (ot, jesteśmy idiotami i zapomnieliśmy, zdarza się) w shell_exec wraz z danymi lecącymi jako coś wprowadzane przez użytkownika bez filtrowania tego (jak już wspomniałem, jesteśmy idiotami). No i w efekcie tego, że zapomnieliśmy się, nasza nieistniejąca stała wywoła notice z PHP, ale zostanie zamieniona na ciąg znaków, złączona z tym czymś od usera i wykonana. Jak już wspomiałem, byliśmy idiotami, więc na pewno nazwaliśmy ją np. "bash", "sh" itp. no bo przecież właśnie tego potrzebowaliśmy.
Założenia są tak masakrycznie absurdalne, że szkoda tego czytać. Na podobnej zasadzie można powiedzieć:
- że PHP jest niebezpieczne, bo ktoś używał md5/sha1 do hashowania haseł zamiast bcrypta z password_hash (albo może sam wymyślił swój "algorytm"?)
- że PHP jest niebezpieczne, bo ktoś nam zrobił SQL Injection - przecież tylko wrzuciliśmy input z formularza prosto w zapytanie, co w tym złego, prawda?
- że PHP jest niebezpieczne, bo na podstawie parametru podanego przez użytkownika chcieliśmy odczytać jakiś plik np. include('../' . $_GET['user_input'])
- że PHP jest niebezpieczne, bo mielismy komentarze na stronie, ale nie filtrowaliśmy i za sprawą XSS ktoś nam wrzucił kod JS z koparką BTC
- że PHP jest niebezpieczne, bo ktoś nam zrobił kuku z CSRF i np. klientom nawrzucał rzeczy do koszyka w sklepie internetowym bo kurcze, przecież nie wiemy nic o tokenach
To nie są błędy języka.
To są błędy i niewiedza programistów.
1. shell_exec może być wyłączone przy pomocy ustawienia disable_functions, choć często jest domyślnie włączone (np. PHP z repo debianowych / ubuntu (wraz z ppa) czy na centosie). Dlaczego? Bo nie ma powodu go wyłączać.
2. Polecenie to służy do odpalania poleceń shellowych (systemowych), a więc daje ogromne możliwości - choć wpływ na to ma masę kwestii (patrz niżej).
3. W PHP mamy do dyspozycji coś takiego jak open_basedir, które limituje nam "widoczność" drzewa katalogów dla PHP i operacji na nich. W efekcie ustawieniem tym - mocno to upraszczając - możemy "zamknąć" interpretatory PHP w np. katalogu witryny aby nie miały nawet możliwości odczytywania tego, co jest wyżej.
4. Nawet jeśli nie ustawimy powyższe, w grę wchodzą ustawienia dostępu do plików, nadal respektowane.
5. Jeśli zechcemy, możemy odpalać PHP (i cały serwer webowy) ze zmienionym katalogiem głównym przy pomocy chroota, co powoduje, że także wszystko w shell_exec jest ograniczone.
6. Na koniec najważniejsze - w dokumencie przedstawiono kod który opiera się na tym, że możemy sobie zdefiniować jakąś stałą, a następnie próbujemy jej użyć gdzieś, gdzie nie mamy jej zdefiniowanej (ot, jesteśmy idiotami i zapomnieliśmy, zdarza się) w shell_exec wraz z danymi lecącymi jako coś wprowadzane przez użytkownika bez filtrowania tego (jak już wspomniałem, jesteśmy idiotami). No i w efekcie tego, że zapomnieliśmy się, nasza nieistniejąca stała wywoła notice z PHP, ale zostanie zamieniona na ciąg znaków, złączona z tym czymś od usera i wykonana. Jak już wspomiałem, byliśmy idiotami, więc na pewno nazwaliśmy ją np. "bash", "sh" itp. no bo przecież właśnie tego potrzebowaliśmy.
Założenia są tak masakrycznie absurdalne, że szkoda tego czytać. Na podobnej zasadzie można powiedzieć:
- że PHP jest niebezpieczne, bo ktoś używał md5/sha1 do hashowania haseł zamiast bcrypta z password_hash (albo może sam wymyślił swój "algorytm"?)
- że PHP jest niebezpieczne, bo ktoś nam zrobił SQL Injection - przecież tylko wrzuciliśmy input z formularza prosto w zapytanie, co w tym złego, prawda?
- że PHP jest niebezpieczne, bo na podstawie parametru podanego przez użytkownika chcieliśmy odczytać jakiś plik np. include('../' . $_GET['user_input'])
- że PHP jest niebezpieczne, bo mielismy komentarze na stronie, ale nie filtrowaliśmy i za sprawą XSS ktoś nam wrzucił kod JS z koparką BTC
- że PHP jest niebezpieczne, bo ktoś nam zrobił kuku z CSRF i np. klientom nawrzucał rzeczy do koszyka w sklepie internetowym bo kurcze, przecież nie wiemy nic o tokenach
To nie są błędy języka.
To są błędy i niewiedza programistów.